Closed GoogleCodeExporter closed 9 years ago
Issue 64 has been merged into this issue.
Original comment by James.Mo...@gmail.com
on 17 Feb 2012 at 12:46
You will have to elaborate on what you are proposing.
Do you mean to have parallel functionality for storing/retrieving artifacts -
functionality that has nothing (currently) to do with Git/Gitblit? Or do you
mean that somehow artifacts within git repositories are exposed in a
maven-style url hierarchy?
I don't personally use the Maven build system (I manually use repo1.maven.org)
but I have to say that Artifactory is most impressive.
Original comment by James.Mo...@gmail.com
on 17 Feb 2012 at 12:53
Thanks for that [ticket merge]. Somehow two tickets got inserted and yet both
tickets lost what I wrote on my CI ambitions for GB.
I meant parallel functionality or a plugin for {artifactory/nexus} s.t. gitblit
acts as a central manager of authentication credentials for artifact
storage/retrieval.
Here is an early sketch of the idea:
//Let's assume that by convention all the projects in a particular git
repository are related.
//Let's assume that by convention a common branch name is nominated for a
particular gitblit hook recipe that is tightly integrated into the gitblit ui.
//The user pushes to the gitblit server.
//gitblit creates a UUID for this 'version' of the entire git repository eg.
GB-XXXX.
//gitblit forks a process that builds and runs each project in the repository.
//When the first project fails, the repository build is abandoned.
//if everything builds ok gitblit deploys the binaries to the mvn repo and tags
the commit with the version number.
//A log is written / the user is notified / the dashboard is updated.
I guess the point I am trying to make is that Hudson/Jenkins loses quite a bit
of rich functionality by being so loosely coupled / SCM neutral. The idea of
having a parallel artifact server (at least initially) is simply to prevent the
mvn repo server to intrude or overcomplicate the design of something relatively
simple like this.
Links:
http://stuartsierra.com/2009/09/08/run-your-own-maven-repository
http://stackoverflow.com/questions/4523727/having-mvn-deploy-in-hudsons-build-go
als-and-the-standard-approach-of-releasi
Original comment by Eric.Faccer@gmail.com
on 20 Feb 2012 at 5:38
I'm a little confused on your definitions of project and repository.
"all projects in a particular git repository are related".
I assume you literally mean multiple projects inside a single git repository.
My confusion stems from this step:
"gitblit creates a UUID for this 'version' of the entire git repository eg.
GB-XXXX."
I should think that the commit id is sufficient here since that points to a
particular tree revision of the entire repository. Unless you meant that a
project might be defined as a single repository and multiple projects would
then have multiple repositories. Then I could see the need for a manufactured
multi-repository identifier.
Not being a Maven or Hudson/Jenkins user it is not clear to me what rich
functionality is lost or how your proposal is an improvement over
Hudson/Jenkins.
To summarize: You propose creating a simple Maven executor that is run on push
to a particular named branch. If the Maven build is successful the generated
artifacts are deployed either to Gitblit's self-hosted Maven repository or to a
full-featured Maven repository such as Nexus/Artifactory. The Maven executor
is an alternative to running an Hudson/Jenkins CI installation.
I'm warming-up to this idea. I think you could prototype almost all of the
mechanics of this using the Groovy push mechanism. You would want to spawn a
thread, though, to prevent the build from blocking the completion of the push.
I suppose there are secondary/implicit requirements here like tracking the
build attempts (start date, success/failure, console log, etc).
Original comment by James.Mo...@gmail.com
on 20 Feb 2012 at 3:01
[deleted comment]
[deleted comment]
To clarify, in my view project.git is a project and /opt/git is the
git.repository or in gitblit parlance the git.repositoriesFolder.
A multi-repository identifier is right. It's a way of keeping track of known
good configurations of a complex multi-project project. Other solutions have
their own limitations.
For example, if proj.git, proj-dep.git, proj-dep2.git have branches 'master',
'gb-featureX' and 'gb-featureY', then a multi-repository identifier can be
built for each configuration on a per name basis. If all gb-branches are built
on a per configuration basis it makes it easy to automatically or manually spin
up or drop complex builds / CI jobs from the command line using branches.
A few advantages over Hudson/Jenkins: HJ is concerned with the health of a
single module, not the health of a project. It can cheat by rebuilding all of
it's projects when a SNAPSHOT dependency is built. This is far from optimal if
you care about pushing as much work as you can away from the user and on to the
build farm.
HJ has no maven server. So to test a build of an arbitrary collection of
modules you have to manually compose those modules. In HJ, there is no
guarantee those modules will work together, especially if they have multiple
parent projects.
A mechanism like this might eventually do away with the need for local builds.
An engineer creates a branch, commits it, gets an IM with the outcome of that
build and if appropriate a URL to test it.
Original comment by Eric.Faccer@gmail.com
on 23 Feb 2012 at 4:34
So you'd have to also group repositories into a Project of some sort so that
they could be rebuilt too, otherwise you are rebuilding everything. Have you
started hacking away on this?
Original comment by James.Mo...@gmail.com
on 23 Feb 2012 at 10:57
Not yet. Still deciding if I need more feedback on the idea before I jump in.
You are welcome to add me gtalk/skype/email if you want to chat about it.
Original comment by Eric.Faccer@gmail.com
on 28 Feb 2012 at 4:36
So the complexity of this is building. Conceptually simple, I suppose, but
then again so is HJ. That is just a web wrapper around some sort of build
script executor. :)
I really do not want to add an RDBMS dependency to the Gitblit design. I'm
thinking that you could go pretty far using a Git repository and its orthogonal
branches model for storing your cross-repository snapshot info. This would
give you lightweight tagging, build history, and rollback power. You could
maintain multiple branches, each one an orphan, to group dependent projects
together. Or you could maintain a separate repo for each project grouping.
This could be a large project. I have some other subprojects in the pipeline
that, for me, will take priority. Currently I'm working on issue 16 (Lucene
integration) for the next release and then I plan to tackle issue 36
(Gitolite-type controls) probably for the following release.
I'm thinking this can broken up into a few smaller pieces that can be rolled
into releases until something is ready. The first one that comes to mind is
your original described thought: basic Maven repository (and perhaps a Maven
proxy too - that was something I was considering for a peripheral project).
Original comment by James.Mo...@gmail.com
on 5 Mar 2012 at 3:38
Hi Eric,
I saw this posting and thought of your tagging multiple repositories idea.
Maybe a you could create a "build" repository which referenced submodule
"project" repositories. That would be a simple and clever way to define a
reproducible buildset and should give you the power to update referenced
submodule project commits.
I have not used submodules myself but I am going to assume that changing a
submodule commit reference is some sort of transaction (commit) which could
inspected and reverted.
http://thomas.apestaart.org/log/?p=1462
Original comment by James.Mo...@gmail.com
on 30 Mar 2012 at 2:09
While I am attracted to the idea of adding cool, unique features to Gitblit, I
think artifact serving and management is better left to other tools that can be
used in conjunction/cooperation with Gitblit.
BTW, I did end up implementing a Maven artifact server/proxy as part of my
Moxie toolkit project (http://moxie.gitblit.com), which is now used to build
Gitblit. I have not yet worked on integrating them, but that might be a rainy
day project.
Thanks for the discussion.
Original comment by James.Mo...@gmail.com
on 3 Jul 2013 at 2:10
Original issue reported on code.google.com by
Eric.Faccer@gmail.com
on 17 Feb 2012 at 4:16