5

We recently migrated from SVN to git. Beside other (unexpected) issues doing releases on git, I am wondering how to deal with the following issue:

When I start a release-run on Jenkins and some developer (accidentally) pushes during the first phase of the release, the release build fails with the following error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on project xyz: Unable to commit files
[ERROR] Provider message:
[ERROR] The git-push command failed.
[ERROR] Command output:
[ERROR] To ssh://[some-ip]/home/git/xyz
[ERROR] ! [rejected]        release/xyz-6.10 -> release/xyz-6.10 (fetch first)
[ERROR] error: failed to push some refs to 'ssh://[some-ip]/home/git/xyz'
[ERROR] hint: Updates were rejected because the remote contains work that you do
[ERROR] hint: not have locally. This is usually caused by another repository pushing
[ERROR] hint: to the same ref. You may want to first integrate the remote changes
[ERROR] hint: (e.g., 'git pull ...') before pushing again.
[ERROR] hint: See the 'Note about fast-forwards' in 'git push --help' for details.
[ERROR] -> [Help 1]

The maven command used by Jenkins to initiate the release build is (we build on Windows, so we unfortunately have to activate -DautoVersionSubmodules due to otherwise too long command line on the git add including all the modified pom.xml):

mvn -B -DdevelopmentVersion=xyz-6.10.0-rc3-SNAPSHOT -DreleaseVersion=xyz-6.10.0-rc2 -Dtag=xyz-6.10.0-rc2 -Dresume=false -e -Dgoals=deploy -DautoVersionSubmodules=true -DcommitByProject=true -P[some-profiles] -T1C release:prepare release:perform -Darguments=-T1C

Is there a simple way to block other users from pushing (but allow Jenkins to push!)? Or any other stable work around - or best practice?

Versions used:

  • Maven 3.3.9
  • Maven Release-Plugin 2.5.3
  • Git 2.8.1
  • Jenkins 1.629
  • Jenkins Maven Release Plug-in Plug-in 0.14.0
  • Windows 10

Thank you in advance for your help.

Tom Fink
  • 532
  • 5
  • 17
  • May I ask the down-voter to leave a message about what I should improve on this question or do better in new questions? It's not encouraging to ask questions, when they are just down-voted without any comment. Thank you! – Tom Fink Jul 18 '16 at 15:15
  • I am facing the same problem, except that there's nobody pushing to the repo, when I perform the release. Is there anything else that could be causing this problem? – Andrew Nov 19 '16 at 20:55

1 Answers1

2

I hope you agree that is was correct that the release failed. And in this case it is not a big issue to fix: update the project and do another release. The easiest way to fix this is: communication :) Simply informing coworkers that you plan to do this release. Another solution I have heard of is: create a branch first and release from this branch. Nobody will change the content of the branch, so this should be a safe solution, but it requires extra work. It's up to you to decide if it's worth it. Most of the time it is not.

Robert Scholte
  • 11,889
  • 2
  • 35
  • 44
  • I hoped my issue was put as clear as possible. My issue is not the failing build, but I am looking for a fail-prove solution to avoid this. As I was assuming there a many companies and organizations out there using the same setup, I was expecting best practices to avoid this error. Of course communication should help. But as I expressed, I am looking for a solution that will always work. Your answer didn't help me at all and from my opinion the down-voting was not justified! – Tom Fink Jul 07 '16 at 09:37
  • 1
    Then go for branching before releasing (as described) – Robert Scholte Jul 07 '16 at 09:59
  • Branching might make sense. But then at least would you revert your downvote? I think it was a legitimate question, to ask for the best possible ways to do this. I never complained about the error being wrong or a mistake. Thank you Robert. – Tom Fink Jul 08 '16 at 11:53