[JIRA] (JENKINS-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times

[h...@coverity.com (JIRA)]

hlau commented on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times I have experienced this issue in various versions of jenkins and parameterized trigger plugin. I have been upgrading both in the far chance that it might have been fixed from work on other bugs for the plugin. I am now using the latest versions: 1.486 for jenkins and 3.16 for parameterized trigger plugin and I'm still seeing the problem. Indeed Job A triggers job B through the post build parameterized trigger plugin using Pass-through Git commit that was built. This is one example of the problem that I saw as recent as in the last hour: Job B was triggered by both #414 and #415 of job A: Started by upstream project A build number 414 originally caused by: Started by remote host 127.0.0.1 Started by upstream project A build number 415 originally caused by: Started by remote host 127.0.0.1 Revision: 495765555ce4db911825ea0b40bca6278669ae72 Note that the git commit hash of 4957 was actually from #414 of job A: Build #414 (Oct 22, 2012 12:28:07 PM) ... Started by remote host 127.0.0.1 Revision: 495765555ce4db911825ea0b40bca6278669ae72 The git commit hash of 4c41 from #415 was not what the triggered job B is building ... in fact, this commit never will get built if no more pushes come in: Build #415 (Oct 22, 2012 1:04:17 PM) ... Revision: 4c41dd60bdff7557133ebfe5229d7f9d06722cef As a result, the developers (justifiably) complain that the latest build artifacts often do not reflect the latest push. Since the continuous integration system is broken, I have to continually monitor the jobs and manually kick them when necessary.

This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira