• Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Minor Minor
    • git-plugin
    • None
    • CentOS 7 + Jenkins 2.53, git-plugin 3.3.0

      checkout scm does not detect the latest commit, if the change is made during the same build.

      Using git multibranch with "Check out to specific local branch" set to empty(same as **)

      Jenkinsfile for testing:

       

      node('somenode'){
      deleteDir()
      checkout scm
      sh 'cat testfile.txt'
      sh 'echo "adding new line" >> testfile.txt'
      sshagent (['your_credentials_id']) {
      sh('git config --local user.name "Your Name"')
      sh('git config --local user.email your@email')
      sh 'git config --local push.default matching'
      sh("git commit -am 'Add data'")
      sh('git push')
      }
      checkout scm
      //checkout([$class: 'GitSCM', branches: [[name: '*/your_branch']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'LocalBranch']], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'your_credentials_id', url: 'ssh://git@url_to_repo.git']]])
      sh 'cat testfile.txt'
      }
      

      Using "checkout([$class: 'GitSCM', ... " (as shown above) instead of "checkout scm", the correct revision is retrieved and the new values should be shown.

      This behaviour is seen on branches with or without slashes (feature/somebranch or somebranch).

      This is possibly related with JENKINS-37263JENKINS-38533 and JENKINS-43468.

       

      Comparing console output between then,  there are some differences.

      Non existent when using "checkout scm" but is shown on "checkout([$class: 'GitSCM', ... "

      Not sure why origin bit is repeated here. "refs/remotes/origin/origin/your_branch^{commit}" but no branch using origin/your_branch exists. Only your_branch.

       

      ...
      git rev-parse refs/remotes/origin/your_branch^{commit} # timeout=10
      git rev-parse refs/remotes/origin/origin/your_branch^{commit} # timeout=10
      ...

       

      refs/remotes/origin/ snippet missing from "checkout scm" but is shown on "checkout([$class: 'GitSCM', ... ".

       

      Checking out Revision your_revision_number (refs/remotes/origin/your_branch) 

          [JENKINS-43761] checkout scm does not detect last commit

          Mark Waite added a comment -

          As far as I understand it, this is behaving as designed for the case with a checkout scm followed later in the job by another checkout scm using the same SHA1 whether or not there were intervening commits on the remote repository.

          jglick detected a bug in the git code for pipeline which would allow the checkout scm used on one node to get a different commit than the checkout scm on another node, even when those two nodes were part of the same pipeline. The fix was made to assure that the use case you're describing (checkout scm, an intervening commit, and another checkout scm in the same pipeline) would checkout the same SHA1.

          Refer specifically to e15a431a and cd6c7cdc.

          Mark Waite added a comment - As far as I understand it, this is behaving as designed for the case with a checkout scm followed later in the job by another checkout scm using the same SHA1 whether or not there were intervening commits on the remote repository. jglick detected a bug in the git code for pipeline which would allow the checkout scm used on one node to get a different commit than the checkout scm on another node, even when those two nodes were part of the same pipeline. The fix was made to assure that the use case you're describing (checkout scm, an intervening commit, and another checkout scm in the same pipeline) would checkout the same SHA1. Refer specifically to e15a431a and cd6c7cdc.

          Nuno Costa added a comment - - edited

          Our workflow would be:

          1. mvn test
          2. If tests ok, bump version on pom file and push changes
          3. mvn deploy with the new version.

          The second checkout is necessary for us because we are using a shared library to run mvn, in parallel(with different build options), inside of a container.

          Could the 2nd checkout using "checkout([$class: 'GitSCM', ... " trigger any issues that I'm not aware?

          Nuno Costa added a comment - - edited Our workflow would be: mvn test If tests ok, bump version on pom file and push changes mvn deploy with the new version. The second checkout is necessary for us because we are using a shared library to run mvn, in parallel(with different build options), inside of a container. Could the 2nd checkout using "checkout([$class: 'GitSCM', ... " trigger any issues that I'm not aware?

          Jesse Glick added a comment -

          Behaving as designed.

          For your use case, you could have the second node check out the tip of the branch, or you could git rev-parse HEAD from the first node to track the commit you just created, and pass that in a local Groovy variable to the second node to check out.

          Jesse Glick added a comment - Behaving as designed. For your use case, you could have the second node check out the tip of the branch, or you could git rev-parse HEAD from the first node to track the commit you just created, and pass that in a local Groovy variable to the second node to check out.

            markewaite Mark Waite
            ncosta Nuno Costa
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: