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

SCM Poll always detects changes - Last build did not detect the right revision

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None
    • Jenkins 2.319.2

      Relevant Plugins:

      Git: 4.10.2
      Bitbucket Branch Source: 751.vda_24678a_f781

      After we changed the authentication method of our Bitbucket Branch Source Plugin to OAuth2, we discovered that all Build Jobs does not detect the right Revision from the last Build.

      This results in an endless loop auf build triggers within the SCM Plugin. I'm not sure, if this is here the right place but I got some Log messages, where we can see, that the last build does not receive the revision from the last build (which is currently running or failed).

      Only if there is a "successfull" build, the scm poll does not logger triggering new builds.

      Here some Logs from: hudson.plugins.git.util.BuildData Level FINEST:

       

      Mar 03, 2022 8:15:12 AM FINEST hudson.plugins.git.util.BuildDatalastBuildRevisionSha1: b5fd154340c91c6a1fddb1660c53fa175736907e does not match sha1:70a7f323f0b867a1075487904ea7482e4e95c566, checking lastBuild.marked
      Mar 03, 2022 8:15:12 AM FINEST hudson.plugins.git.util.BuildDatalastBuildMarkedSha1: b5fd154340c91c6a1fddb1660c53fa175736907e does not match sha1:70a7f323f0b867a1075487904ea7482e4e95c566
      Mar 03, 2022 8:15:12 AM FINEST hudson.plugins.git.util.BuildDataNo match found in getLastBuild for sha1:70a7f323f0b867a1075487904ea7482e4e95c566, returning null

      This is the Output of build #106.

      See here the Build History:

      In the gaps I disabled the SCM Poll.

      All the builds have the following SCM Information:

      All the prevois builds are also building the Revision 70a7f32. So the excpected behavior would be, that the git SCM also detects the running and failed built revision (70a.. instead of b5fd - see log) to avoid this infinite loop of build triggers.

      Could you help us? Currently we disabled the whole SCM Poll feature

       

          [JENKINS-67939] SCM Poll always detects changes - Last build did not detect the right revision

          Mark Waite added a comment -

          I believe I've seen cases like this when the polling frequency was longer than the build frequency. The best solution in those cases is to switch from polling the repository to use webhooks that notify Jenkins when a commit arrives on the repository. See Kohsuke's blogpost "polling must die" and various videos that describe techniques to configure webhooks.

          Mark Waite added a comment - I believe I've seen cases like this when the polling frequency was longer than the build frequency. The best solution in those cases is to switch from polling the repository to use webhooks that notify Jenkins when a commit arrives on the repository. See Kohsuke's blogpost "polling must die" and various videos that describe techniques to configure webhooks.

          Norbert Koch added a comment -

          Thanks, we will investigate that, for this we have to assign an external address to Jenkins.

          But just for keep in mind, we didn't had this behavior before.
          And the changes list are now alaways empty, although there were changes:

          I cannot assess if this is caused by the Git Plugin or the Bitbucket Branch Source Plugin

          Norbert Koch added a comment - Thanks, we will investigate that, for this we have to assign an external address to Jenkins. But just for keep in mind, we didn't had this behavior before. And the changes list are now alaways empty, although there were changes: I cannot assess if this is caused by the Git Plugin or the Bitbucket Branch Source Plugin

          Mark Waite added a comment - - edited

          I'm reasonably confident that I've seen the issue in the git plugin but have never found the specific conditions that are known to cause it.

          Sometimes I've been able to resolve it by copying the job to a new name then deleting the job at the old name and renaming the job from the new name to the old name.

          Mark Waite added a comment - - edited I'm reasonably confident that I've seen the issue in the git plugin but have never found the specific conditions that are known to cause it. Sometimes I've been able to resolve it by copying the job to a new name then deleting the job at the old name and renaming the job from the new name to the old name.

          Norbert Koch added a comment -

          Many thanks for your fast replies.

          That's a bit unlucky, because the Projects and Jobs are prepared by Bitbucket Branch Plugin. A recreation is that easy and takes some effort. We figured out, that this is happening on all projects and branches.

          Nevertheless I agree, that the best way would be to work with the webhook, but it is still confusing.

          Norbert Koch added a comment - Many thanks for your fast replies. That's a bit unlucky, because the Projects and Jobs are prepared by Bitbucket Branch Plugin. A recreation is that easy and takes some effort. We figured out, that this is happening on all projects and branches. Nevertheless I agree, that the best way would be to work with the webhook, but it is still confusing.

            Unassigned Unassigned
            norbertkoch_v Norbert Koch
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: