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

    Details

    • Similar Issues:

      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

            Hide
            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"
                }
            }
            
            Show
            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" } }
            Hide
            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.

            Show
            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.
            Hide
            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\""
            

             

            Show
            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\""  
            Hide
            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.

            Show
            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.
            Hide
            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

            Show
            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

              People

              • Assignee:
                Unassigned
                Reporter:
                pgeorgiev Pavel Georgiev
              • Votes:
                5 Vote for this issue
                Watchers:
                14 Start watching this issue

                Dates

                • Created:
                  Updated: