How to use Jenkins job(s) with dependent git repositories and multiple branches

Question

We have 2 git repositories, Platform and US (we have other geo-specific ones as well which is why they are split, but they are not necessarily relevant here). US depends on Platform.

We are using git-flow (meaning new features are in their own branches like feature/some-product , develop branch is somewhat more stable and represents QA-ready builds, master branch is stable and for releases). (If a feature has both Platform and US parts, there will be a branch in each with the same name.) We decided that the Jenkins jobs for the features should not run mvn deploy because we don't want to publish them to the snapshot repository and probably shouldn't run mvn install because we don't want a different feature branch to grab it from Jenkins's local repo (this we are less sure about though). We believe they should only make sure everything compiles and that the unit tests pass ( mvn verify ).

This is where the problem comes in, because these are separate git repositories and we are not doing anything with the compiled jar ( install or deploy ),

• how can we safely expose the compiled jars from the Platform job to the US without exposing them to other developers or jobs (or is this even a concern is only doing mvn install ) or
• how can one Jenkins job build Platform and US for a specific branch together?

If we only have a single actively developed branch (or we were using subversion) this would not be an issue.

Some ideas we have (and concerns with each)

• For feature branches use a different version (eg, 8.1.0-SNAPSHOT-some-product ).
  • This seems like a lot of work for every feature branch.
  • It seems like it'd clog up the local repo with "stale" jars, and we would need to worry about purging them.
• Somehow use git submodule to checkout Platform's and US's feature/some-product and either use mvn verify --reactor or a simple pom file with the top level projects as modules.
  • How to make Jenkins add the submodules?
  • If the submodules were already there, there would need to be a whole git repo for this, which seems redundant.
  • --reactor doesn't work always.
  • How to supply the pom file?
• Just do mvn install .
  • feature/other-thing may only be on US, so after Platform feature/some-product publishes to Jenkins local repository (which may be very different from Platform develop , which US feature/other-thing would be built against normally), it would (We think) cause US feature/other-thing to fail (or pass!) in a false sense (supposing that if it were compiled against Platform develop it could possibly get a different result).

Answer 1

I have not had to address this issue personally.... here is my thoughts on how I would look at the issue:

If you MUST only have one job for both branches (a bad idea), you can use parameterized build plugin to pass in the text string "US" or "Platform" and have logic in a shell script that will check out the relevant repo's branch.

HOWEVER, this eliminates the ability to have repo polling kickoff the build. You would have to set up a build schedule on a cron and you would get a new build no matter what, even if the repo hasn't changed (unless your batch / shell script is smart enough to check for changes).

I don't see any reason NOT to have two separate Jenkins Jobs, one for each branch.

If one job needs access to the .jars (aka the build artifacts) then you can always reference the artifacts of any other jar from the job's "LATEST" URL on the jenkins server. Be sure the jobs specify what artifacts need to get archived.

Answer 2

The way I ended up solving this is using the maven versions plugin. I had to make sure all the modules were managed dependencies in the top-level project, but that may have been a different issue. Also, I am sure of this, the US project will need to explicitly declare its version even if it is the same as the parent.

They both poll git but the Platform job also triggers US if it built successfully.

The way the versions plugin works will require you to do this in two steps. Add 2 "Invoke top-level Maven targets" in the job, the second is the clean deploy . The first is a little different for the Platform and US.

Platform: mvn versions:set -DnewVersion=yourBranchName-${project.version} .

US: mvn versions:update-parent -DparentVersion=yourBranchName-${project.version} versions:set -DnewVersion=yourBranchName-${project.version}

If the branch only exists on the US repository, then obviously don't make the Platform one, and the US one is the same command as what the Platform one's would have been.

One final issue I ran into was originally I had the new version as ${project.version}-yourBranchName but the issue here was that the repository the job was deploying to only accepted snapshots and because the version didn't end in -SNAPSHOT it gave error code 400.