1

We have an in-house tool that manages multiple components over several repositories into one project; similar in nature to Google's repo tool (https://code.google.com/p/git-repo/) or gitslave (http://gitslave.sourceforge.net/). Our projects aren't just one single git repository.

The dependencies are defined in a "meta" repository which is always checked out first and then dependencies are checked out afterwards.

I'm investigating Jenkins and trying to find a way to get it to use our tool to checkout a work area with multiple repositories.

Has anyone done this sort of thing before? I'm at a bit of a loss with the Jenkins documentation and not really sure where to start.

Steve Folly
  • 8,327
  • 9
  • 52
  • 63
  • I think you will need to chain jenkins jobs together to get this to work, I think the jeknins-git plugin will allow selection for one repo/branch only.... other post here might be helpful :http://stackoverflow.com/questions/14843696/checkout-multiple-git-repos-into-same-jenkins-workspace – mconlin Oct 12 '13 at 18:36

2 Answers2

1

Since you want to use your tool, you can just run it in your first build step (or as a pre build step for maven builds). As @Electrawn already mentioned, you will loose your revision numbers. However, there are work arounds for this as well. However, if you can write a properties file with the revision numbers you can load the properties file with the EnvInject plugin. From that point on you will have access to the properties in the build job. You also loose Jenkins ability to check for changes automatically. If you home grown tool supports this feature, you can create a second job which only checks for changes and triggers the build job when changes were found.

This was just one possible workaround. With a little bit creativity, you can come up with different solutions.

The best way of course is to write your own Jenkins plugin. Since you have the major part already done (writing your own tool), you only need to implement the Jenkins API. ... or what might be faster, update the current git plugin to fit your project structure.

Peter Schuetze
  • 16,185
  • 4
  • 44
  • 58
0

Subversion (and the jenkins subversion plugin) allows this via SVN:Externals easily. Personal opinion aside...

Since git has no easy external functionality built in, you are best off adding multiple pre build steps of shell calls to just checkout the various parts of the repository you want. You won't be able to get automagic REVISION numbers like other SCM plugins.

SCM Plugin to check out the main project

Build task one (assuming linux):

git clone REPO %{WORKSPACE}/source/project2

Build task two:

git clone REPO %{WORKSPACE}/source/project3

You can then investigate modularizing your jobs and shoving artifacts together into chains per the first commenter, but lets get you building your project in one massive job first.

Electrawn
  • 2,254
  • 18
  • 24