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

Global Pipeline Libraries triggers the 'poll SCM' of jobs

    XMLWordPrintable

Details

    • Bug
    • Status: Reopened (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • linux rhel7.2
      jenkins 2.19.2
      up to date 'workflow' set of plugins (on stable update center)

    Description

      I have this situation where :

      • I have some jobs that gets sources from a SCM, and performs a 'poll SCM' hourly
      • I have a 'global pipeline lib' defined, on another SCM (doesn't matter really, what atters is it's not in the same source tree s the jobs)

      My issue is that any commit to the 'global pipeline lib' SCM will be detected by all the jobs that have a 'poll SCM' configured.

      I wish I can exclude the global lib from polling.

      (and yes, I know, polling is evil, whenever I can I have triggers configured on modern scm to push jobs, but sometimes it's just not possible, believe me you don't want to know all the why's)

      Attachments

        Issue Links

          Activity

            For everyone who may still facing this problem, please refer to the workaround mentioned here. I can confirm it solves the problem.

            eocampos Eliseo Ocampos added a comment - For everyone who may still facing this problem, please refer to the workaround mentioned here . I can confirm it solves the problem.

            Running a full pipeline might take a long time... especially if you have 10s or 100s that are affected by the issue. Does anyone know if there's a way to alter the config proactively (manually) via the job's XML file?

            brianjenkins Brian Villanueva added a comment - Running a full pipeline might take a long time... especially if you have 10s or 100s that are affected by the issue. Does anyone know if there's a way to alter the config proactively (manually) via the job's XML file?
            chris_knight Chris Knight added a comment -

            "Include @Library changes in job recent changes" did fix this issue for us.  However, importantly, we had to restart our Jenkins server for this to take effect. 

            chris_knight Chris Knight added a comment - "Include @Library changes in job recent changes" did fix this issue for us.  However, importantly, we had to restart our Jenkins server for this to take effect. 
            richmond Rich added a comment -

            For me, "Include @Library changes in job recent changes" did stop the changes from appearing in change log but a change in shared library is still triggering the build.

            richmond Rich added a comment - For me, "Include @Library changes in job recent changes" did stop the changes from appearing in change log but a change in shared library is still triggering the build.

            In our case we hade changelogs for global shared libraries enabled but wanted to disable them to avoid rebuilds on library changes. However, doing so made all jobs which currently are failing, entering a infinite build loop due to scm poll. I have figured out that the the scm poll seems to always consider all repositories with changelog/state of the last sucessfull build. This can even be a build you don't see in the web interface. I found following cure:

            1. Go to the SCM Poll log of the job and find the "old" state (For us this is subversion: "changed from <xxxxx>")
            2. Find file "permalinks" in  ${JENKINS_HOME}/jobs/<affected project>/builds
            3. Within that file get the build number of last successfull build
            4. Edit ${JENKINS_HOME}/jobs/<affected project>/builds/<build_nr>/build.xml. (Probably make  copy of that file before) In that file, find tag "revisionStates". This tag will have subtags "entry" were one of this subtags will match the affected repo and "old state" determined above. Remove the entire entry. Save file.
            amesser Andreas Messer added a comment - In our case we hade changelogs for global shared libraries enabled but wanted to disable them to avoid rebuilds on library changes. However, doing so made all jobs which currently are failing, entering a infinite build loop due to scm poll. I have figured out that the the scm poll seems to always consider all repositories with changelog/state of the last sucessfull build. This can even be a build you don't see in the web interface. I found following cure: Go to the SCM Poll log of the job and find the "old" state (For us this is subversion: "changed from <xxxxx>") Find file "permalinks" in  ${JENKINS_HOME}/jobs/<affected project>/builds Within that file get the build number of last successfull build Edit ${JENKINS_HOME}/jobs/<affected project>/builds/<build_nr>/build.xml. (Probably make  copy of that file before) In that file, find tag "revisionStates". This tag will have subtags "entry" were one of this subtags will match the affected repo and "old state" determined above. Remove the entire entry. Save file.

            People

              Unassigned Unassigned
              squalou squalou jenkins
              Votes:
              42 Vote for this issue
              Watchers:
              56 Start watching this issue

              Dates

                Created:
                Updated: