13
votes

As the title says, I'm trying to get an automated release job working on Hudson. It's a Maven project, and all the code is in Git. Manually, I do the release on my personal machine like so:

git checkout master
mvn -B release:prepare release:perform

This works perfectly. The Maven release plugin properly pushes the release tag to the origin repository as well as the next commit that bumps the version to the next SNAPSHOT.

However, when I run this same Maven job through Hudson (either by creating my own "release" job or by using the M2 Release Plugin) it doesn't work so well. The release tag gets pushed out to the origin repository, and the release gets pushed out to our Nexus repository, but the subsequent commit that bumps the version to the next SNAPSHOT doesn't go out. Furthermore, the "master" branch in the origin repository doesn't get changed at all. I've looked in Hudson's workspace for the job, however, and the version has been updated.

After looking at the output from the Hudson job, it appears that the Git plugin does not actually checkout "master", but rather it's SHA1 id. That is, if the "master" branch label points to commit "f6af76f541f1a1719e9835cdb46a183095af6861", Hudson does

git checkout -f f6af76f541f1a1719e9835cdb46a183095af6861

instead of

git checkout -f master

As a result, the changes that the Maven release plugin is making are not actually on any branch (certainly not on "master") and these changes don't make it to the origin repository. It runs on the right code, but bookkeeping-wise, the changes seem to get lost because no branch label points to them.

Has anybody gotten the Hudson + Git + Maven Release Plugin combo to work properly? Is there some additional configuration somewhere I can set to make this happen? Or is this a bug in the Hudson Git plugin?

Thanks in advance.

5
It looks like the same problem is mentioned in Jenkins maillist, in Hudson maillist, in JIRA HUDSON-5856, on GitHub gist. Also explanation about detached HEAD is relative.dma_k

5 Answers

5
votes

Edited to eliminate out of date info.

See this answer for the current (non-hacky) solution.

3
votes

After fiddling around with things a bit more, I tried setting my automated release as a standalone job (i.e., not using the M2 Release Plugin). Instead of having the job set up to "build a maven2 project", I made it a "Build a free-style software project" job. The first thing it does is execute a shell command:

git checkout master

The next step is a Maven invocation, configured thusly:

-e -B release:prepare release:perform

That first shell command is the key; now that I'm actually on a branch, all the changes the release plugin performs get pushed back to the origin repository.

While this technically answers my own question, I'm still curious as to others' experiences with this combination of Hudson + Git + Maven Release plugin.

Thanks

2
votes

If I understand correctly, this behavior is intentional because Nigel does not believe that maven should commit to the SCM. There is a relatively painless workaround (though it would be better not to have to work around anything). I use the Hudson M2 Extra Steps plugin and do a pre-build step:

git checkout master || git checkout -b master

git reset --hard origin/master

This executes after git has checked out the sha-1 but before maven starts building. Doing it this way allows me to set master to whatever the git plugin has checked out. I then use the maven-release-plugin to perform releases, and the SCM changes and deployment work fine.

0
votes

@meowsqueak: I had the same problem and patched the plugin to add a variable called "GIT_BRANCH" to the build environment. If you want to try it out, the modified plugin is available for download @github: http://github.com/jberkel/Hudson-GIT-plugin/downloads. I've also contacted the upstream author to get it merged into the mainline. Of course this doesn't solve the problem of the detached HEAD, but at least your build scripts know what branch you're in.

0
votes

I know it's old question but still neeed good answer. Do what's suggested here: https://blogs.adobe.com/jzitting/maven-release-builds-with-jenkins-and-git/ "The solution was to set the “Checkout/merge to local branch (optional)” option under advanced Git settings on the Jenkins build configuration screen." I placed there "HEAD" and know releasing works.