|
||||||||||||
|
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 |
||||||||||||
- [JIRA] (JENKINS-14394) The version 1.... [email protected] (JIRA)
- [JIRA] (JENKINS-14394) The versi... [email protected] (JIRA)
- [JIRA] (JENKINS-14394) The versi... [email protected] (JIRA)
- [JIRA] (JENKINS-14394) The versi... [email protected] (JIRA)
- [JIRA] (JENKINS-14394) The versi... [email protected] (JIRA)
- [JIRA] (JENKINS-14394) The versi... [email protected] (JIRA)

I've created another patch, based off 2283620895c888f5f02f06fcac2fb33f1def0691 .
Apparently, the problem is the use of a build parameter in the "branch to build" field. I have a series of jobs which should all run on the same target revision; the first one is kicked off by an automated system, and it passes the "revision to test" into the later ones as a parameter. This change punts along the environment and uses it to expand variables where necessary.
I am unsure why matching a pattern against an exactly equal string seems to fail, but I put in a direct .equals() check to handle that case. If you can figure out why it's necessary and fix it better, I'd appreciate it.
With this patch I have no further issues with the git-scm plugin.