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

Global pipeline library & simple 'checkout scm' rebuilds each polling cycle

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None
    • Refer to docker image referenced in description
      git plugin 3.3.0
      git client plugin 2.4.2

      Simple 'checkout scm' with polling defined will always detect changes even when there are no changes. May be related to the added complexity from multiple repositories being polled (since the example job definition uses a global pipeline library).

      More complicated checkout does not have the same issue.

      Steps I took to duplicate the problem:

      1. Copy JDK 8 tar file into my public_html/jdk directory
          $ mkdir -p ~/public_html/jdk/
          $ cp jdk-8u131-linux-*tar.gz ~/public_html/jdk/
        
      2. Copy the jenkins-bugs repo into a local bare repo for faster cloning later
          $ mkdir -p ~/git/bare/bugs/
          $ cd ~/git/bare/bugs/
          $ git clone --mirror https://github.com/MarkEWaite/jenkins-bugs
        
      3. Clone, build, and run the docker instance
          $ git lfs clone https://github.com/MarkEWaite/docker-lfs JENKINS-43754
          $ cd JENKINS-43754
          $ git lfs fetch origin origin/lts-with-plugins
          $ git checkout -b lts-with-plugins origin/lts-with-plugins
          $ docker build -t jenkins:JENKINS-43754 .
          $ VOL1=~/public_html:/var/jenkins_home/userContent/
          $ VOL2=~/git/bare:/var/lib/git/mwaite/
          $ docker run -i --rm --publish 8080:8080 --volume $VOL1 --volume $VOL2 jenkins:JENKINS-43687
        
      4. Connect a web browser to that docker instance (http://localhost:8080)
      5. Open the "Bugs - Pipeline Checks" folder
      6. Open the "jenkins-bugs" multi-branch pipeline job
      7. Click the "Scan Multibranch Pipeline" link and then the "Run Now" link to start branch indexing
      8. Confirm the JENKINS-43687 job runs successfully
      9. Commit a change to the JENKINS-43687 branch, and push the change
          $ git clone https://github.com/MarkEWaite/jenkins-bugs
          $ cd jenkins-bugs
          $ git checkout -b JENKINS-43754 -t origin/JENKINS-43754
          $ ant increment
          $ git push
        
      10. Wait 7 minutes while watching the git polling log, confirm the job runs without a change, if the simple checkout scm is used, and does not run without changes if the more complex checkout is used

          [JENKINS-43754] Global pipeline library & simple 'checkout scm' rebuilds each polling cycle

          Mark Waite created issue -
          Mark Waite made changes -
          Environment Original: Refer to docker image referenced in description New: Refer to docker image referenced in description
          git plugin 3.3.0
          git client plugin 2.4.2
          Mark Waite made changes -
          Description Original: Simple 'checkout scm' with polling defined will always detect changes even when there are no changes. May be related to the added complexity from multiple repositories being polled (since the example job definition uses a global pipeline library).

          More complicated checkout does not have the same issue.

          Steps I took to duplicate the problem:
          # Copy JDK 8 tar file into my public_html/jdk directory
          {code}
            $ mkdir -p ~/public_html/jdk/
            $ cp jdk-8u131-linux-*tar.gz ~/public_html/jdk/
          {code}
          # Copy the jenkins-bugs repo into a local bare repo for faster cloning later
          {code}
            $ mkdir -p ~/git/bare/bugs/
            $ cd ~/git/bare/bugs/
            $ git clone --mirror https://github.com/MarkEWaite/jenkins-bugs
          {code}
          # Clone, build, and run the docker instance
          {code}
            $ git lfs clone https://github.com/MarkEWaite/docker-lfs JENKINS-43687
            $ cd JENKINS-43687
            $ git lfs fetch origin origin/lts-with-plugins
            $ git checkout -b lts-with-plugins origin/lts-with-plugins
            $ docker build -t jenkins:JENKINS-43687 .
            $ VOL1=~/public_html:/var/jenkins_home/userContent/
            $ VOL2=~/git/bare:/var/lib/git/mwaite/
            $ docker run -i --rm --publish 8080:8080 --volume $VOL1 --volume $VOL2 jenkins:JENKINS-43687
          {code}
          # Connect a web browser to that docker instance (http://localhost:8080)
          # Open the "Bugs - Pipeline Checks" folder
          # Open the "jenkins-bugs" multi-branch pipeline job
          # Click the "Scan Multibranch Pipeline" link and then the "Run Now" link to start branch indexing
          # Confirm the JENKINS-43687 job runs successfully
          # Commit a change to the JENKINS-43687 branch, and push the change
          {code}
            $ git clone https://github.com/MarkEWaite/jenkins-bugs
            $ cd jenkins-bugs
            $ git checkout -b JENKINS-43687 -t origin/JENKINS-43687
            $ ant increment
            $ git push
          {code}
          # Wait 7 minutes while watching the git polling log, confirm the job runs without a change, if the simple checkout scm is used, and does not run without changes if the more complex checkout is used
          New: Simple 'checkout scm' with polling defined will always detect changes even when there are no changes. May be related to the added complexity from multiple repositories being polled (since the example job definition uses a global pipeline library).

          More complicated checkout does not have the same issue.

          Steps I took to duplicate the problem:
          # Copy JDK 8 tar file into my public_html/jdk directory
          {code}
            $ mkdir -p ~/public_html/jdk/
            $ cp jdk-8u131-linux-*tar.gz ~/public_html/jdk/
          {code}
          # Copy the jenkins-bugs repo into a local bare repo for faster cloning later
          {code}
            $ mkdir -p ~/git/bare/bugs/
            $ cd ~/git/bare/bugs/
            $ git clone --mirror https://github.com/MarkEWaite/jenkins-bugs
          {code}
          # Clone, build, and run the docker instance
          {code}
            $ git lfs clone https://github.com/MarkEWaite/docker-lfs JENKINS-43754
            $ cd JENKINS-43754
            $ git lfs fetch origin origin/lts-with-plugins
            $ git checkout -b lts-with-plugins origin/lts-with-plugins
            $ docker build -t jenkins:JENKINS-43754 .
            $ VOL1=~/public_html:/var/jenkins_home/userContent/
            $ VOL2=~/git/bare:/var/lib/git/mwaite/
            $ docker run -i --rm --publish 8080:8080 --volume $VOL1 --volume $VOL2 jenkins:JENKINS-43687
          {code}
          # Connect a web browser to that docker instance (http://localhost:8080)
          # Open the "Bugs - Pipeline Checks" folder
          # Open the "jenkins-bugs" multi-branch pipeline job
          # Click the "Scan Multibranch Pipeline" link and then the "Run Now" link to start branch indexing
          # Confirm the JENKINS-43687 job runs successfully
          # Commit a change to the JENKINS-43687 branch, and push the change
          {code}
            $ git clone https://github.com/MarkEWaite/jenkins-bugs
            $ cd jenkins-bugs
            $ git checkout -b JENKINS-43754 -t origin/JENKINS-43754
            $ ant increment
            $ git push
          {code}
          # Wait 7 minutes while watching the git polling log, confirm the job runs without a change, if the simple checkout scm is used, and does not run without changes if the more complex checkout is used
          Mark Waite made changes -
          Link New: This issue duplicates JENKINS-43468 [ JENKINS-43468 ]
          Mark Waite made changes -
          Link New: This issue is related to JENKINS-43687 [ JENKINS-43687 ]
          Mark Waite made changes -
          Summary Original: Global pipeline library and simple 'checkout scm' with polling rebuilds each polling cycle New: Global pipeline library & simple 'checkout scm' rebuilds each polling cycle
          Mark Waite made changes -
          Assignee Original: Mark Waite [ markewaite ]
          Mark Waite made changes -
          Link Original: This issue is related to JENKINS-43687 [ JENKINS-43687 ]

          My workaround is to add a checkbox that the user has to check to force the rebuild to actually happen. :-/

          Aaron D. Marasco added a comment - My workaround is to add a checkbox that the user has to check to force the rebuild to actually happen. :-/

          Another workaround would involve checking the new currentBuild.getBuildCauses() provided by JENKINS-41272.

          Aaron D. Marasco added a comment - Another workaround would involve checking the new currentBuild.getBuildCauses() provided by JENKINS-41272 .
          Aaron D. Marasco made changes -
          Link New: This issue is related to JENKINS-41272 [ JENKINS-41272 ]

            Unassigned Unassigned
            markewaite Mark Waite
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: