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

Jobs continuously triggered even with change in configuration

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None
    • Jenkins 2.46.3
      Parameterized Trigger Plugin 2.35.1
      OS Debian 8
      git 2.1.4
      Git client plugin 2.5.0
      Git plugin 3.5.1
      Git server plugin 1.7

      Hello,

      I've got a "strange" issue on Jenkins for some jobs (only 2 or 3 among 60). They are continuously building, like there is always change in the code base, but this is unfortunately not the case.

      In the beginning, I had the job triggered on "Poll SCM", then during the time to find the issue I've decided to change the configuration on "Build periodically" (as you can see on first joined screen). But this did not fixed the issue. In deed, the job kept building as there is a change in code base (see second joined screen, sorry it is in French...)

      Polling log does not say anything (literally) . Changes log and Jenkins log neither.

      Currently I had to disable the jobs.

      Thank you for any lead.

       

        1. 2017-07-17.png
          2017-07-17.png
          40 kB
        2. 2017-07-17-2.png
          2017-07-17-2.png
          11 kB
        3. Capture du 2017-08-22 17-09-35.png
          Capture du 2017-08-22 17-09-35.png
          24 kB
        4. Capture du 2017-08-22 17-09-49.png
          Capture du 2017-08-22 17-09-49.png
          24 kB
        5. screenshot-1.png
          screenshot-1.png
          12 kB

          [JENKINS-45570] Jobs continuously triggered even with change in configuration

          More info :

          In the log I have only one "INFOS: SCM changes detected in XXX Triggering #20" for multiple " hudson.model.Run execute"

          Alexandre Baillif added a comment - More info : In the log I have only one "INFOS: SCM changes detected in XXX Triggering #20" for multiple " hudson.model.Run execute"

          Adding two screenshots of two builds

          Alexandre Baillif added a comment - Adding two screenshots of two builds

          Alexandre Baillif added a comment - - edited

          Ok, I think I got it :

          *Steps to reproduce : *
          Get a project with at least two branches ending with the same name, e.g. :
          a/ master
          b/ toto/master

          Use the git client plugin and git plugin to perform the checkout as :

          Set the trigger SCM to poll changes.

          Build a first time
          Commit something
          Wait
          The job goes to infinite builds

          Alexandre Baillif added a comment - - edited Ok, I think I got it : *Steps to reproduce : * Get a project with at least two branches ending with the same name, e.g. : a/ master b/ toto/master Use the git client plugin and git plugin to perform the checkout as : Set the trigger SCM to poll changes. Build a first time Commit something Wait The job goes to infinite builds

          Mark Waite added a comment -

          I suspect that is a problem due to the legacy behavior that the git plugin applies to a branch named "origin/branch" where "origin/branch" is allowed to be ambiguously interpreted as either the name of the origin repository followed by the name of the branch, or as the name of a branch called "origin/branch".

          You may be able to resolve that issue by using a different form of branch name. For example, instead of specifying the branch name as "toto/master", you might try "refs/heads/toto/master" or "remotes/origin/toto/master" or "refs/remotes/origin/toto/master" or ":origin/toto/master". Refer to the online help for the different forms of branch name references for experimentation.

          The legacy behavior really can't be changed, since there are many users who depend on that behavior. The alternate branch name specifications tend to give more precise control of the branch name than the simple form.

          Mark Waite added a comment - I suspect that is a problem due to the legacy behavior that the git plugin applies to a branch named "origin/branch" where "origin/branch" is allowed to be ambiguously interpreted as either the name of the origin repository followed by the name of the branch, or as the name of a branch called "origin/branch". You may be able to resolve that issue by using a different form of branch name. For example, instead of specifying the branch name as "toto/master", you might try "refs/heads/toto/master" or "remotes/origin/toto/master" or "refs/remotes/origin/toto/master" or ":origin/toto/master". Refer to the online help for the different forms of branch name references for experimentation. The legacy behavior really can't be changed, since there are many users who depend on that behavior. The alternate branch name specifications tend to give more precise control of the branch name than the simple form.

          Mark Waite added a comment -

          I think this is describing a problem in the git plugin (most likely) rather than an issue in the parameterized trigger plugin.

          Mark Waite added a comment - I think this is describing a problem in the git plugin (most likely) rather than an issue in the parameterized trigger plugin.

          I also think the problem comes from the Git Plugin (updating this issue) and using "refs/head/" seems to fix the issue. But this is kind of tricky.

          The issue does not only appear with master, I also got it with branches named "release/1.01" and "1.01" for instance. It is like it detects branches only by the last name after "/" and it does not do that every time. I don't know what is triggering the issue.

          Also I noticed that the log says that it detects "Multiple candidate revisions" therefore it registers another build to "catch up" but, and I think this is why with get infinite builds, it launches every build with the same commit id. And so it never "catches up".

          Last but not least, I've never experienced the issue yet with Pipeline build.

          Alexandre Baillif added a comment - I also think the problem comes from the Git Plugin (updating this issue) and using "refs/head/" seems to fix the issue. But this is kind of tricky. The issue does not only appear with master, I also got it with branches named "release/1.01" and "1.01" for instance. It is like it detects branches only by the last name after "/" and it does not do that every time. I don't know what is triggering the issue. Also I noticed that the log says that it detects "Multiple candidate revisions" therefore it registers another build to "catch up" but, and I think this is why with get infinite builds, it launches every build with the same commit id. And so it never "catches up". Last but not least, I've never experienced the issue yet with Pipeline build.

            Unassigned Unassigned
            alexb Alexandre Baillif
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: