-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins 2.85, GitHub Branch Source 2.2.3, GitHub 1.28.0, Pipeline 2.5, Pipeline: Multibranch 2.16
Currently at the last passing build of master, pipeline-github/job/core/job/master/44/
I can see that it has successfully built revision 29e70493c0598970cc10aa60134ce72739bc938d.
A few hours ago Jenkins kicked off master/45. If I look in the console log for the new build, it says:
Obtained Jenkinsfile from 29e70493c0598970cc10aa60134ce72739bc938d
This looks like the same commit to me, so I'd like the plugin to explain why it's rebuilding something which is already known to be green. We can't have builds doing this unnecessarily, because there are almost 100 pull requests which haven't merged yet because they haven't been able to fully build due to various other Jenkins issues. (In the meantime, I'm going to have to manually kill it... but now the status is going to be grey...)
What we know:
- Nobody kicked it off manually (Status would show the name of the user who did it)
- The configuration didn't change from the previous build (we are using a plugin which shows an icon if that occurs)
The cause of a build should identify what is triggering, e.g.
Then you can look at the indexing or event logs to trace the actual trigger.
Alternatively be aware that if you are using templating or jobdsl to create your multibranch project and it does not preserve a consistent source.id, every time the source.id changes you will trigger a rebuild