Make gitblit a basic maven repo

[GoogleCodeExporter]

How awesome would that be? Huge win.

Original issue reported on code.google.com by Eric.Faccer@gmail.com on 17 Feb 2012 at 4:16

[GoogleCodeExporter]

Issue 64 has been merged into this issue.

Original comment by James.Mo...@gmail.com on 17 Feb 2012 at 12:46

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: WontFix