-
Bug
-
Resolution: Not A Defect
-
Minor
-
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-37263, JENKINS-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)
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.