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

checkout scm doesn't take revision that started the pipeline

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None
    •  Jenkins 2.176.4, git-plugin 3.12.1

      Pipeline job

      checkout scm doesn't take revision that started the pipeline instead takes last (fresh) commit from branch 

      Related to doc:

      https://jenkins.io/doc/book/pipeline/jenkinsfile/

      The checkout step will checkout code from source control; scm is a special variable which instructs the checkout step to clone the specific revision which triggered this Pipeline run.

       
      To reproduce:

      • Merge to branch (abc)
      • start pipeline
      • pipeline waits for continue (input message)
      • push new change to branch (xyz)
      • resume pipeline

      Expect:

      • pipeline resume abc

      Observe:

      • pipeline resume xyz
         

      Workaround for as - use explicit checkout git commit

      variable GIT_COMMIT we defined at the beginning of Pipeline: 

      def scmVars = checkout scm
      env.GIT_COMMIT = scmVars.GIT_COMMIT

       

      And we see that checkout show different results:

       

      checkout scm: [$class: 'GitSCM', branches: [[name: "${GIT_COMMIT}"]]]
      sh 'cat new_files'
      // abc

       

      checkout scm
      sh 'cat new_files'
      // xyz

       

      It's a bug or feature? according to the doc - bug... (git plugin?)

       

      Can be related with JENKINS-59071 or JENKINS-43761

       

          [JENKINS-60591] checkout scm doesn't take revision that started the pipeline

          ipleten added a comment -

          This is should be a "Major" issue, as we can't achieve reliable build results, especially than documentation says it should work in that way.

          ipleten added a comment - This is should be a "Major" issue, as we can't achieve reliable build results, especially than documentation says it should work in that way.

          Mark Waite added a comment - - edited

          I've confirmed the code behaves as described in a multibranch pipeline. I'm not sure if the issue is in the git plugin or in the pipeline plugin that provides the configuration for the checkout scm step or in the use of the scm step.

          The test job that I created uses a scripted multibranch pipeline to wait 90 seconds before performing the first checkout. During the 90 seconds while the job is waiting, another process pushes a new commit to the central repository. The checkout scm step then runs and takes the new commit instead of taking the commit that provided the Jenkinsfile.

          Refer to the verification job on the JENKINS-60591 branch of my jenkins-bugs repository.

          Declarative pipeline could likely create the same conditions by disabling default checkout.

          The documentation for the scm variable in a non-multibranch pipeline says:

          Represents the SCM configuration in a multibranch project build. Use checkout scm to check out sources matching Jenkinsfile. You may also use this in a standalone project configured with Pipeline from SCM, though in that case the checkout will just be of the latest revision in the branch, possibly newer than the revision from which the Pipeline was loaded.

          I interpret that to mean that if you're expecting to get the version which matches the Jenkinsfile in a non-multibranch Pipeline, you will need to specifically request it. I've confirmed that interpretation is correct.

          When a pipeline that is not multibranch retrieves the Jenkinsfile from SCM using a lightweight checkout, it reports "Obtained Jenkinsfile from https://github.com/MarkEWaite/jenkins-bugs". When it is not a lightweight checkout, it does not report 'Obtained Jenkinsfile' in the log at all. When the same is done in a multibranch pipeline, it reports 'Obtained Jenkinsfile from <SHA-1>'.

          Mark Waite added a comment - - edited I've confirmed the code behaves as described in a multibranch pipeline. I'm not sure if the issue is in the git plugin or in the pipeline plugin that provides the configuration for the checkout scm step or in the use of the scm step. The test job that I created uses a scripted multibranch pipeline to wait 90 seconds before performing the first checkout. During the 90 seconds while the job is waiting, another process pushes a new commit to the central repository. The checkout scm step then runs and takes the new commit instead of taking the commit that provided the Jenkinsfile. Refer to the verification job on the JENKINS-60591 branch of my jenkins-bugs repository . Declarative pipeline could likely create the same conditions by disabling default checkout. The documentation for the scm variable in a non-multibranch pipeline says: Represents the SCM configuration in a multibranch project build. Use checkout scm to check out sources matching Jenkinsfile. You may also use this in a standalone project configured with Pipeline from SCM, though in that case the checkout will just be of the latest revision in the branch, possibly newer than the revision from which the Pipeline was loaded. I interpret that to mean that if you're expecting to get the version which matches the Jenkinsfile in a non-multibranch Pipeline, you will need to specifically request it. I've confirmed that interpretation is correct. When a pipeline that is not multibranch retrieves the Jenkinsfile from SCM using a lightweight checkout, it reports "Obtained Jenkinsfile from https://github.com/MarkEWaite/jenkins-bugs ". When it is not a lightweight checkout, it does not report 'Obtained Jenkinsfile' in the log at all. When the same is done in a multibranch pipeline, it reports 'Obtained Jenkinsfile from <SHA-1>'.

            Unassigned Unassigned
            mzol Mykhailo Zolotarenko
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: