|
||||||||
|
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 |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
Same here. Workaround does not work for me. Does it matter what order the additional behaviors have?
My concrete problem:
2 branches: A and B
Job is parameterized so I can tell which branch to build.
Job scans both branches (by origin/**) every hour to check for changes.
Jenkins raises the build number within the pom files.
Commits by Jenkins user should be ignored and not cause the job to run.
When the last build was in branch A and changes in branch B (by scanning origin/**) are detected, the build for branch B gets kicked off correctly. Unfortunately also changes in branch A (raised build number by jenkins)are detected an d another build gets scheduled, leaving this message in the log:
Multiple candidate revisions
Scheduling another build to catch up with (BUILD) my faulty job
From that point on, the job switches between branch A and B every time and is scheduling the other branch to get build every time causing an endless loop.