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

[mushko1212@gmail.com (JIRA)]

Mykhailo Zolotarenko created an issue

Jenkins / JENKINS-60591 checkout scm doesn't take revision that started the pipeline Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 2019-12-26 17:49 Priority: Minor Reporter: Mykhailo Zolotarenko 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   Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[tamerlaha@gmail.com (JIRA)]

ipleten commented on JENKINS-60591

Re: checkout scm doesn't take revision that started the pipeline 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.

Add Comment

[mark.earl.waite@gmail.com (JIRA)]

Mark Waite commented on JENKINS-60591

Re: checkout scm doesn't take revision that started the pipeline

I've confirmed this bug behaves as described. 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. 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. I haven't checked the behavior with pipelines that are not multibranch.

Add Comment

[mark.earl.waite@gmail.com (JIRA)]

Mark Waite assigned an issue to Unassigned

Jenkins / JENKINS-60591

checkout scm doesn't take revision that started the pipeline

Change By: Mark Waite Assignee: Mark Waite

Add Comment

[mark.earl.waite@gmail.com (JIRA)]

Mark Waite edited a comment on JENKINS-60591

Re: checkout scm doesn't take revision that started the pipeline

I've confirmed this bug the code behaves as described.  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|https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-60591/Jenkinsfile] on the [JENKINS-60591 branch|https://github.com/MarkEWaite/jenkins-bugs/tree/JENKINS-60591] of my [jenkins-bugs repository|https://github.com/MarkEWaite/jenkins-bugs].

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

I haven't checked the behavior with pipelines that are not multibranch.   The documentation for the {{scm}} variable in a non-multibranch pipeline says: bq. 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.

Add Comment

[mushko1212@gmail.com (JIRA)]

Mykhailo Zolotarenko updated an issue

Jenkins / JENKINS-60591

checkout scm doesn't take revision that started the pipeline

Change By: Mykhailo Zolotarenko Environment: Jenkins 2.176.4, git-plugin 3.12.1

Add Comment

[mushko1212@gmail.com (JIRA)]

Mykhailo Zolotarenko updated an issue

Jenkins / JENKINS-60591 checkout scm doesn't take revision that started the pipeline

Change By: Mykhailo Zolotarenko Priority: Minor Major

Add Comment

[mushko1212@gmail.com (JIRA)]

Mykhailo Zolotarenko updated an issue

Jenkins / JENKINS-60591 checkout scm doesn't take revision that started the pipeline Change By: Mykhailo Zolotarenko

+ _{color:#172b4d} Pipeline job{color}_+ _{color:#172b4d} checkout scm{color}_ 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:

{code:java}

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

// abc{code}   {code:java}

checkout scm sh 'cat new_files'

// xyz{code}

It's a bug or feature? according to the doc - bug... (git plugin?)   Can be related with JENKINS-59071 or JENKINS-43761

Add Comment

[mark.earl.waite@gmail.com (JIRA)]

Mark Waite edited a comment on JENKINS-60591

Re: checkout scm doesn't take revision that started the pipeline 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|https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-60591/Jenkinsfile] on the [JENKINS-60591 branch|https://github.com/MarkEWaite/jenkins-bugs/tree/JENKINS-60591] of my [jenkins-bugs repository|https://github.com/MarkEWaite/jenkins-bugs]. Declarative pipeline could likely create the same conditions by disabling default checkout. I haven't checked the behavior with pipelines that are not multibranch.  The documentation for the {{scm}} variable in a non-multibranch pipeline says: bq. 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.

Add Comment

[mark.earl.waite@gmail.com (JIRA)]

Mark Waite edited a comment on JENKINS-60591

Re: checkout scm doesn't take revision that started the pipeline

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|https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-60591/Jenkinsfile] on the [JENKINS-60591 branch|https://github.com/MarkEWaite/jenkins-bugs/tree/JENKINS-60591] of my [jenkins-bugs repository|https://github.com/MarkEWaite/jenkins-bugs]. Declarative pipeline could likely create the same conditions by disabling default checkout. I haven't checked the behavior with pipelines that are not multibranch.  The documentation for the {{scm}} variable in a non-multibranch pipeline says: bq. 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>'.

Add Comment

[mark.earl.waite@gmail.com (JIRA)]

[mark.earl.waite@gmail.com (JIRA)]

[mark.earl.waite@gmail.com (JIRA)]