Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-47515

Pipeline rebuilds commits which have already passed without stating why

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major 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)

          [JENKINS-47515] Pipeline rebuilds commits which have already passed without stating why

          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

          Stephen Connolly added a comment - 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

          trejkaz added a comment -

          What it actually says is just "Branch indexing":

          But then when I get to that page, it says:

          The two revision numbers stated here don't even match the revision number stated on the front page, so which one can I trust?

          trejkaz added a comment - What it actually says is just "Branch indexing": But then when I get to that page, it says: The two revision numbers stated here don't even match the revision number stated on the front page, so which one can I trust?

          Keep in mind that if you have a shared library then you can end up with multiple checkouts. Then if the shared library does not do the actual checkout correctly you will not see the changes for that checkout in the build

          Stephen Connolly added a comment - Keep in mind that if you have a shared library then you can end up with multiple checkouts. Then if the shared library does not do the actual checkout correctly you will not see the changes for that checkout in the build

            Unassigned Unassigned
            trejkaz trejkaz
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: