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

    XMLWordPrintable

Details

    Description

      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

      Attachments

        Issue Links

          Activity

            0x89 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"
                }
            }
            
            0x89 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" } }
            jglick 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.

            jglick 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.
            icereval 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\""
            

             

            icereval 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\""  
            jekeller 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.

            jekeller 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

            nddeshmukh16 Nandlal Deshmukh added a comment - Facing the same issue, do any one get any solution or work around for it. Thanks in advance Nandlal
            danielbeck 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.

            danielbeck 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.
            jglick 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.

            jglick 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.

            People

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

              Dates

                Created:
                Updated: