Closed snoopotic closed 9 years ago
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.
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"}
@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.
@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.
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.
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.
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?
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
@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.
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)