since 2.5.0: GIT_BRANCH set to detached when sha1 parameter set in notifyCommit URL

[snoopotic]

Hi, please see/vote this issue: https://issues.jenkins-ci.org/browse/JENKINS-24133 THe Update to 2.5.0 caused Problems to our setups. We decided to downgrade to 2.4.2 instead of applying the workaroudn described there...

Can anything be done on Plugin-side? (e.g. disable sending the sha1sum)

[mikesir87]

Haha... just had a conversation about this in my blog post's comment thread yesterday. There currently isn't a Stash plugin-side workaround. I could add an option to disable the sending of the sha1 hash. But, I have no global configuration settings page (yet) and having to set this flag on everyone repository would be quite a pain.

May just be time to introduce a global config page that has only this flag (for now) and let it be overridden on the repo level. In the meantime, rolling back to 2.4.2 will work.

[felipebn]

Guys, this was a issue for me because we use the ${GIT_BRANCH} macro to set the build display name on Jenkins via build-name-setter plugin.

[EDITED] Actually the way i thought was working wasn't. So i used the pre-scm-buildstep plugin to create a properties file using the following shell command:

git reflog show --all | grep `echo $GIT_COMMIT | cut  -c1-7` | sed "s/.*\/\(.*\)@{.*/git.branch=\1/g" > jenkins_build.properties

Basically it set the property git.branch on the file jenkins_build.properties to the branch name found using the first 7 chars from commit id.

At the build-name-setter plugin property I used this macro ${PROPFILE,file="jenkins_build.properties",property="git.branch"}

[Floyd25]

@felipebn Your (edited) fix nearly works. BUT: For some strange reason $GIT_COMMIT contains the sha1 of the previous (!) commit when running the shell script you noted. Really strange behaviour that results in build names containing the Branch Name of the previous commit. It seems as if $GIT_COMMIT gets updates after the scm run is finished.

[felipebn]

@Floyd25 It's true. We noticed this few days ago and unfortunately I didn't had enough time to update here since. This happens because the pre-scm-buildstep runs before git checkout and at this time the variable $GIT_COMMIT isn't updated yet with the build revision.

We solved it by removing the pre-scm-buildstep and using the Environment Script Plugin which is executed between scm and build-name-setter plugin.

With the Environment Script Plugin we used the same shell to create the jenkins_build.properties file.

[pmv]

We'll be staying on 2.4.2 until this is fixed. A global setting may be nice, however, even if this was at the repo level we would use it. In fact, a repo level override setting may be nice anyway for teams who don't have global admin access or don't agree with the global setting.

[hendrikhalkow]

I fixed this by adding an 'omit SHA1 hash code' checkbox, which can be used until the issue in the Jenkins Gut olugin is fixed. A pull request has been submitted.

[pablaasmo]

I have tested usage of the 'omit SHA!' checkbox. It works. When can we get this pushed to the Atlassian repo so that we can easily update the plugin in Stash?

[efekthalo]

still present in 2.6.0, on "Trigger build" from Stash checking "Omit SHA1 Hash Code" solves the #detached issue, but disables the "Trigger build" button

[mikesir87]

@efekthalo That is correct and, unfortunately, a fallout of not using the hash code. When not sending the hash code, the Jenkins plugin performs a poll to see if any changes actually occurred. If so, a build is triggered. When providing the hash, Jenkins doesn't poll and goes straight to a build.

Since notifications are sent with each push to Stash, the "Trigger Build" button can't successfully re-trigger a build without the use of the hash. I guess it wouldn't be a bad idea to disable the button/display some sort of note on the button when not using hashcodes.