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

Manual SCM Polling for pipeline starts even though no changes on branch

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
    • Similar Issues:

      Description

      Manually setting a pipeline job to poll SCM is resulting in a build being triggered each and every time polling starts.

      In reviewing logs, the only change I see is the TAG created by the build itself.  No other commits are in place.

      Typical pipeline configuration is to poll SCM for change, build component, TAG the commit of the successful build, and post step will deleteDir() after each build.

      While a tag is not seen as a commit, it is clear that in GIT, a tag is given a unique hash.

      I have tried ignoring commits by the build user, but since the tag is not a code change, this does not work.

      I have tried ignoring commits with messages, but since the tag is not seen as a commit, this does not work.

      I have tried using a REGEX to ignore tags, however I am getting errors with the regex and illegal characters, so this has not worked either.

       

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment -

          Please update your git plugin and git client plugin to the released versions instead of the release candidate. Those release candidates are not being maintained since the official release of git plugin 4.0.0 and git client 3.0.0. May not resolve the issue but will avoid a number of other serious problems in those release candidates.

          Show
          markewaite Mark Waite added a comment - Please update your git plugin and git client plugin to the released versions instead of the release candidate. Those release candidates are not being maintained since the official release of git plugin 4.0.0 and git client 3.0.0. May not resolve the issue but will avoid a number of other serious problems in those release candidates.
          Hide
          lbenhart lee benhart added a comment -

          Thanks Mark, I will do so, however we were seeing this with the earlier versions as well. I had to disable polling altogether about a year ago.  I had first thought it was purely related to bitbucket.  I re-enabled polling after we migrated our repositories to github, the issue persists.

          Show
          lbenhart lee benhart added a comment - Thanks Mark, I will do so, however we were seeing this with the earlier versions as well. I had to disable polling altogether about a year ago.  I had first thought it was purely related to bitbucket.  I re-enabled polling after we migrated our repositories to github, the issue persists.
          Hide
          markewaite Mark Waite added a comment -

          My suspicion is that the tag is unrelated to the decision being made by the git plugin to start another build. Sometimes, jobs that are building on every poll will stop building on every poll when the branch name being built is changed from */master to refs/heads/master. The more specific reference avoids inadvertent detection of other changes which are unrelated to the specific branch.

          Show
          markewaite Mark Waite added a comment - My suspicion is that the tag is unrelated to the decision being made by the git plugin to start another build. Sometimes, jobs that are building on every poll will stop building on every poll when the branch name being built is changed from */master to refs/heads/master . The more specific reference avoids inadvertent detection of other changes which are unrelated to the specific branch.
          Hide
          lbenhart lee benhart added a comment - - edited

          Mark, I would be inclined to agree with you however we have the develop branch and the master branch on two separate pipelines, so the branch is not being changed. I also updated the branch spec to use refs/head/${branch}. Could the issue be related to deleting the workspace in the post, after we have tagged? Could it be because we are tagging using git command line within the pipeline?

          Show
          lbenhart lee benhart added a comment - - edited Mark, I would be inclined to agree with you however we have the develop branch and the master branch on two separate pipelines, so the branch is not being changed. I also updated the branch spec to use refs/head/${branch}. Could the issue be related to deleting the workspace in the post, after we have tagged? Could it be because we are tagging using git command line within the pipeline?
          Hide
          markewaite Mark Waite added a comment -

          I don't expect tagging and change detection to be related unless the check for remote changes is also looking for tags. As far as I recall, it is not checking for new tags, just new commits.

          Show
          markewaite Mark Waite added a comment - I don't expect tagging and change detection to be related unless the check for remote changes is also looking for tags. As far as I recall, it is not checking for new tags, just new commits.

            People

            • Assignee:
              Unassigned
              Reporter:
              lbenhart lee benhart
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: