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

Polling always finds changes when you checkout 2 branches of the same repo in the pipeline

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • jenkins 2.46.3
      git plugin 3.3.0
      pipeline 2.5

      I have a jenkins multibranch pipeline that is building the product, the tests and runs them.

      The product git repo contains the Jenkinsfile and the GitLab webhook is configured on the product git repo. In order to run the tests i need to :

      • checkout the master branch of the tests git repo - to setup the product (the master can install any supported upgrade path)
      • checkout the maintenance branch of the same tests git repo to run the tests applicable for the product installed

      Since the webhook/Jenkins file is configured on the product git repo i have configured scm polling for the master/maintenance branch of the tests git repo.

      However whenever the git pooling triggers it always finds changes in the tests git repo although there are none.

       

      Note: Just to be clear both branches of the tests git repo are checked out in separate folders.

       

      Expected behavior:

      The polling should consider the repo+branch combination as a separate entity, i.e.

      • change in tests repo master branch only - trigger a build
      • change in tests repo maintenance branch only - trigger a build
      • change in both tests repo master and maintenance branch - trigger a build
      • no changes in tests repo master/maintenance branches - no build triggered

       

      NOTE: Original comment added in https://issues.jenkins-ci.org/browse/JENKINS-39621

          [JENKINS-44762] Polling always finds changes when you checkout 2 branches of the same repo in the pipeline

          Martin Sander added a comment -

          To reproduce, use this simple pipeline definition:

          node {
              stage('checkout') {
                  ws() {
                      git 'https://github.com/jenkinsci/pipeline-examples.git'
                  }
                  ws() {
                      git branch: 'pipeline', url: 'https://github.com/jenkinsci/pipeline-examples.git'
                  }
              }
              
              stage('check branch') {
                  sh "git branch -a"
              }
          }
          

          Martin Sander added a comment - To reproduce, use this simple pipeline definition: node { stage( 'checkout' ) { ws() { git 'https: //github.com/jenkinsci/pipeline-examples.git' } ws() { git branch: 'pipeline' , url: 'https: //github.com/jenkinsci/pipeline-examples.git' } } stage( 'check branch' ) { sh "git branch -a" } }

          Jesse Glick added a comment -

          Probably another symptom of the well-known failure of the git plugin to correctly implement SCM APIs (see BuildData). No one has figured out how to refactor it without causing regressions for thousands of users.

          Jesse Glick added a comment - Probably another symptom of the well-known failure of the git plugin to correctly implement SCM APIs (see BuildData ). No one has figured out how to refactor it without causing regressions for thousands of users.

          Michael Haselton added a comment - - edited

          Thought I'd share a quick workaround for this limitation so others might save a bit of time. Basically you can always fall back to orchestrating the git clone/checkout yourself and avoid the broken machinery which ignores `poll: false` w/ checkout/git-plugin calls. 

          // WORKAROUND: Polling always finds changes when you checkout 2 branches of the same repo in the pipeline
          // https://issues.jenkins-ci.org/browse/JENKINS-39621
          // https://issues.jenkins-ci.org/browse/JENKINS-44762
          //
          sh "git init"
          sh "git remote add -t ${GIT_OTHER_BRANCH} -f origin ${GIT_URL}"
          sh "git checkout ${GIT_OTHER_BRANCH}"
          //
          // checkout(changelog: false, poll: false, scm: [$class: "GitSCM",
          //     branches: [[name: GIT_OTHER_BRANCH]],
          //     extensions: [
          //         [$class: "LocalBranch", localBranch: GIT_OTHER_BRANCH],
          //     ],
          //     userRemoteConfigs: [[url: GIT_URL]],
          // ])
          
          writeFile(file: ".gitignore", text:
              "# output from nohup\n" +
              "nohup.out"
          )
          
          sh "git config user.email \"jenkins@example.com\""
          sh "git config user.name \"Jenkins CI User\""
          

           

          Michael Haselton added a comment - - edited Thought I'd share a quick workaround for this limitation so others might save a bit of time. Basically you can always fall back to orchestrating the git clone/checkout yourself and avoid the broken machinery which ignores `poll: false` w/ checkout/git-plugin calls.  // WORKAROUND: Polling always finds changes when you checkout 2 branches of the same repo in the pipeline // https://issues.jenkins-ci.org/browse/JENKINS-39621 // https://issues.jenkins-ci.org/browse/JENKINS-44762 // sh "git init" sh "git remote add -t ${GIT_OTHER_BRANCH} -f origin ${GIT_URL}" sh "git checkout ${GIT_OTHER_BRANCH}" // // checkout(changelog: false , poll: false , scm: [$class: "GitSCM" , // branches: [[name: GIT_OTHER_BRANCH]], // extensions: [ // [$class: "LocalBranch" , localBranch: GIT_OTHER_BRANCH], // ], // userRemoteConfigs: [[url: GIT_URL]], // ]) writeFile(file: ".gitignore" , text: "# output from nohup\n" + "nohup.out" ) sh "git config user.email \" jenkins@example.com\"" sh "git config user.name \" Jenkins CI User\""  

          Jacob Keller added a comment - - edited

          I think this has to do with multiple git clones in pipeline don't store the build data properly, resulting in inability to correctly identify that a previous build has already built on that second git clone.

          Jacob Keller added a comment - - edited I think this has to do with multiple git clones in pipeline don't store the build data properly, resulting in inability to correctly identify that a previous build has already built on that second git clone.

          Facing the same issue, do any one get any solution or work around for it.

          Thanks in advance

          Nandlal

          Nandlal Deshmukh added a comment - Facing the same issue, do any one get any solution or work around for it. Thanks in advance Nandlal

          Daniel Beck added a comment -

          I had this problem in a Pipeline that ran

          git credentialsId: 'github', poll: false, url: 'https://github.com/org/repo', branch: branch

          on different nodes with different branches. Polling kept causing new builds in an infinite build loop.

          Adding changelog: false made the problem go away. For this project I don't care about the changelog, so that was no problem for me.

          Daniel Beck added a comment - I had this problem in a Pipeline that ran git credentialsId: 'github', poll: false, url: 'https://github.com/org/repo', branch: branch on different node s with different branch es. Polling kept causing new builds in an infinite build loop. Adding changelog: false made the problem go away. For this project I don't care about the changelog, so that was no problem for me.

          Jesse Glick added a comment -

          I suspect this is due to GitSCM.getKey ignoring branches. Thus, WorkflowJob.pollingBaselines has a single entry for both checkouts, corresponding to the repo location, despite the branches being distinct.

          Jesse Glick added a comment - I suspect this is due to GitSCM.getKey ignoring branches . Thus, WorkflowJob.pollingBaselines has a single entry for both checkouts, corresponding to the repo location, despite the branches being distinct.

            Unassigned Unassigned
            pgeorgiev Pavel Georgiev
            Votes:
            5 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated: