[JIRA] [workflow-plugin] (JENKINS-26100) SCM steps should return revision state

Yes, as documented under env in Pipeline Syntax » Global Variables this is not yet supported. You need to git rev-parse HEAD etc.

This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

jglick@cloudbees.com (JIRA)

unread,

Jun 21, 2016, 5:51:12 PM6/21/16

to jenkinsc...@googlegroups.com

Jesse Glick commented on

For a multibranch Pipeline job (Jenkinsfile), it would be straightforward to expose the SCMRevision as a special Groovy variable, as it is Serializable. Depending on the SCM source, you will get various available properties, such as hash in the case of Git branches (JENKINS-33161 would offer pullHash for pull request builds), though these would need to be marked @Whitelisted too.

For general use including non-multibranch builds it would be desirable to get variables generically from the checkout step though this would require a core API change (JENKINS-24141). For the case of the git and svn convenience steps these could directly return the revision.

jglick@cloudbees.com (JIRA)

unread,

Aug 29, 2016, 1:17:22 PM8/29/16

to jenkinsc...@googlegroups.com

Jesse Glick updated an issue

Jenkins /

SCM steps should return revision state

Change By:	Jesse Glick
Component/s:	workflow-scm-step-plugin
Component/s:	pipeline

yury.zaytsev@traveltainment.de (JIRA)

unread,

Oct 11, 2016, 3:22:02 AM10/11/16

to jenkinsc...@googlegroups.com

Yury Zaytsev commented on

I understand that this is still not implemented, therefore one needs to go the rev-parse way, but is there a possibility to modify scm object to use the correct revision, instead of making a brand new one, like

 
                                                                checkout([$class: 'GitSCM', branches: [[name: 'XXX']], extensions: [[$class: 'SubmoduleOption', parentCredentials: true], [$class: 'CleanCheckout']], userRemoteConfigs: [[credentialsId: 'YYY', url: 'ZZZ']]])

and basically have to duplicate all the SCM settings? Sorry for a newb Groovy question, if this is trivial.

jglick@cloudbees.com (JIRA)

unread,

Oct 11, 2016, 12:06:06 PM10/11/16

to jenkinsc...@googlegroups.com

Jesse Glick commented on

modify scm object to use the correct revision

If by “correct revision” you just mean “the same revision I checked out somewhere earlier in the build”, then for multibranch Pipelines this is automatic when you do checkout scm. For simple projects using CpsScmFlowDefinition it is not possible due to limitations in the SCM API; it would be possible to provide an alternate FlowDefinition that uses scm-api, i.e. branch sources, and which provides the same guarantee of a consistent revision across calls to checkout scm.

yury.zaytsev@traveltainment.de (JIRA)

unread,

Oct 12, 2016, 3:50:06 AM10/12/16

to jenkinsc...@googlegroups.com

Yury Zaytsev updated an issue

Jenkins /

SCM steps should return revision state

Change By:	Yury Zaytsev
Attachment:	multibranch-wrong-revision.png

yury.zaytsev@traveltainment.de (JIRA)

unread,

Oct 12, 2016, 3:50:11 AM10/12/16

to jenkinsc...@googlegroups.com

Yury Zaytsev commented on

> If by “correct revision” you just mean “the same revision I checked out somewhere earlier in the build”, then for multibranch Pipelines this is automatic when you do checkout scm.

I'm very surprised to hear that. Multibranch pipeline project is exactly what I have. In my pipeline, I have multiple stages, which all do checkout scm for now, and inside each stage I have checkouts on multiple workers in parallel. The pipeline currently runs for an hour, or so, and if someone commits when the pipeline is already running, the checkout scm in the next stage picks up new commits, and not the commit with which the pipeline has been started.

I want checkout scm to always checkout the commit which triggered the build, and not the branch which triggered the build, whatever the branch state is. Please see a screenshot attached...

yury.zaytsev@traveltainment.de (JIRA)

unread,

Oct 12, 2016, 3:58:03 AM10/12/16

to jenkinsc...@googlegroups.com

Yury Zaytsev commented on

Just to clarify what you see on the screenshot: first it started building revision 3dc9d2b (1 commits since the last build), but then someone merged another branch while the pipeline was running, and checkout scm in the later stages picked up the new state 0825e24 (4 commits more), which is two merge commits away from the last build. Now, in the meantime, build #83 has been triggered with 0825e24, and both kept running in parallel, which, of course, doesn't make any sense.

Ideally, I would like newer builds to abort previous ones as they get to the end of the stage, but, in the mean time, at least checkout scm should always checkout the same thing within one build.

So, thank you for answering, but I can't see how what you're saying is correct.

jarosite@gmail.com (JIRA)

unread,

Oct 12, 2016, 5:31:02 AM10/12/16

to jenkinsc...@googlegroups.com

aleksey savitskiy commented on

why are you not using stash? checkout once, stash files, and then unstash in multiple times on nodes and stages.

yury.zaytsev@traveltainment.de (JIRA)

unread,

Oct 12, 2016, 5:59:03 AM10/12/16

to jenkinsc...@googlegroups.com

Yury Zaytsev commented on

aleksey savitskiy my repository is ~2G large and I have lots of small files in it. Very unfortunately, stash is simply not usable for anything beyond a couple of dozens of megabytes and hundreds of files.

jglick@cloudbees.com (JIRA)

unread,

Oct 12, 2016, 11:04:15 AM10/12/16

to jenkinsc...@googlegroups.com

Jesse Glick commented on

if someone commits when the pipeline is already running, the checkout scm in the next stage picks up new commits, and not the commit with which the pipeline has been started

Then that is a bug, which should be filed separately with complete, self-contained steps to reproduce from scratch. The version consistency guarantee of checkout scm does have test coverage, including of course for Git.

I want checkout scm to always checkout the commit which triggered the build

Well there is not necessarily any such commit, or unique commit. What is guaranteed is that the repository revision from which Jenkinsfile was loaded whenever the build actually started running will match that of any subsequent checkout scm commands.

jenkinsjira@marcuscobden.co.uk (JIRA)

unread,

Nov 4, 2016, 10:12:09 AM11/4/16

to jenkinsc...@googlegroups.com

Marcus Cobden commented on

I'm seeing the issue where `checkout scm` results in different commits between the start/end of a build; I've made a separate bug with a reproduction example: https://issues.jenkins-ci.org/browse/JENKINS-39508

nolange79@gmail.com (JIRA)

unread,

Feb 7, 2020, 5:42:06 AM2/7/20

to jenkinsc...@googlegroups.com

Norbert Lange commented on

I might be dense, but I still dont understand how I would do this with a declarative pipeline (without script blocks).
Any help here?

withCheckout is nowhere to be found

the env variables are not set by default:

 
                                                                pipeline {
    agent none
    stages {
        stage('checkout') {
            post { always { deleteDir() } }
            agent any
            steps {
                checkout([$class: 'GitSCM', 
                    userRemoteConfigs: [[url: 'https://github.com/docker/for-linux.git']]])
                sh 'set'
            }
        }
    }
}
 
                                                            

trying to stuff into a withEnv block fails with `java.lang.UnsupportedOperationException: must specify $class with an implementation of interface java.util.List`

 
                                                                pipeline {
    agent none
    stages {
        stage('checkout') {
            post { always { deleteDir() } }
            agent any
            steps {
                withEnv(checkout([$class: 'GitSCM', 
                    userRemoteConfigs: [[url: 'https://github.com/docker/for-linux.git']]])) {
                        sh 'set'  
                    }
            }
        }
    }
}
 
                                                            

Jenkins ver. 2.219 (docker alpine installation)
git 4.1.1 true
git-client 3.1.1 true
workflow-scm-step 2.10 true

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

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

unread,

Feb 7, 2020, 9:45:21 AM2/7/20

to jenkinsc...@googlegroups.com

Mark Waite commented on

Norbert Lange could you review the Jenkins Minute video "Using Git Environment Variables" and see if it resolves your issue?

If it resolves your issue, then I'll add a git plugin documentation section on using the git plugin with Pipeline and will embed that video in the new section.

nolange79@gmail.com (JIRA)

unread,

Feb 7, 2020, 10:05:05 AM2/7/20

to jenkinsc...@googlegroups.com

Norbert Lange commented on

Mark Waite: No, video is generally a bad idea, and that specific one is not helping at all.

Here is the problem in a single paragraph:

 
                                                                checkout()
// returns ""
sh 'echo ${GIT_COMMIT}'
// returns "null"
echo "${env.GIT_COMMIT}"
 
                                                            

No environment variables are set.

kristyk.ashton@gmail.com (JIRA)

unread,

Feb 7, 2020, 10:28:13 AM2/7/20

to jenkinsc...@googlegroups.com

Kristy ashton commented on

Inter Milan vs AC Milan Soccer Live Streaming Online 2020
https://fb5531.pb.online/
https://medium.com/@kristyk.ashton/inter-milan-vs-ac-milan-soccer-live-streaming-online-2020-d29a41ee1cfa
https://medium.com/@kristyk.ashton/inter-milan-vs-ac-milan-soccer-live-streaming-online-2020-d29a41ee1cfa
https://medium.com/@kristyk.ashton/inter-milan-vs-ac-milan-soccer-live-streaming-online-2020-d29a41ee1cfa
https://medium.com/@kristyk.ashton/inter-milan-vs-ac-milan-soccer-live-streaming-online-2020-d29a41ee1cfa
https://medium.com/@kristyk.ashton/inter-milan-vs-ac-milan-soccer-live-streaming-online-2020-d29a41ee1cfa

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

unread,

Feb 7, 2020, 11:05:06 AM2/7/20

to jenkinsc...@googlegroups.com

Mark Waite commented on

Norbert Lange it looks to me like you're using declarative pipeline but then ignoring the default checkout which declarative pipeline provides for you, without explicitly stating that you intend to skip the default checkout. If you intend to skip the default checkout then you should extend your declarative pipeline with

 
                                                                options {
    skipDefaultCheckout()
}

If you don't intend to skip the default checkout, then the techniques described in that video will work.

If you intend to skip the default checkout, specify your own checkout, and use the return value from the checkout step to collect the settings used in the checkout, then it appears you'll need to use a script block in your declarative Pipeline. Refer to this example that I created while experimenting with the question. The example skips the default checkout, performs its own checkout, and assigns the return value of checkout() to the variable results. It then displays values from results.

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

unread,

Feb 7, 2020, 11:18:05 AM2/7/20

to jenkinsc...@googlegroups.com

Mark Waite commented on

Norbert Lange also, since this bug report is about the git step and not the checkout step, it would be better to use a different location for your question and for the answer to your question. When you ask a question in an issue, you limit the number of people that will answer the question to only those that are monitoring that bug. A question asked in the Jenkins mailing lists or the Jenkins chat channels can be seen by a much larger group.

nolange79@gmail.com (JIRA)

unread,

Feb 7, 2020, 11:19:04 AM2/7/20

to jenkinsc...@googlegroups.com

Norbert Lange commented on

Yeah, I posted the entire declarative pipeline couple posts before.

I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode.

What is a default checkout: where would the pipeline know the url from?
Does withCheckout exist? its referenced in this thread.
Would be nice to get withEnv working like I illustrated above.

Docs send you completely in the wrong direction unfortunately.

nolange79@gmail.com (JIRA)

unread,

Feb 7, 2020, 11:20:05 AM2/7/20

to jenkinsc...@googlegroups.com

Norbert Lange edited a comment on

Yeah, I posted the entire declarative pipeline couple posts before.

I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode.

What is a default checkout: where would the pipeline know the url from?

Does *withCheckout* exist? its referenced in this thread.
Would be nice to get *withEnv* working like I illustrated above.

Docs send you completely in the wrong direction unfortunately.

Edit: I replied here because this is often referenced as "answer"

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

unread,

Feb 7, 2020, 11:34:04 AM2/7/20

to jenkinsc...@googlegroups.com

Mark Waite commented on

> I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode.

The variables are available if you don't use the checkout step in the declarative pipeline. The declarative pipeline has an implicit checkout step that happens before the Pipeline executes.

> What is a default checkout: where would the pipeline know the url from?

When the Jenkinsfile for the Pipeline is read from SCM, the declarative pipeline uses that URL.

> Does withCheckout exist? its referenced in this thread.

No, withCheckout does not exist. It was added to the scm step plugin May 5, 2017 and then removed on May 16, 2017.

> Docs send you completely in the wrong direction unfortunately.

Which docs send you in the wrong direction?

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

unread,

Feb 7, 2020, 11:35:04 AM2/7/20

to jenkinsc...@googlegroups.com

Mark Waite edited a comment on

> bq. I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode.

The variables are available if you don't use the {{checkout}} step in the declarative pipeline. The declarative pipeline has an implicit checkout step that happens before the Pipeline executes.

> bq. What is a default checkout: where would the pipeline know the url from?

When the Jenkinsfile for the Pipeline is read from SCM, the declarative pipeline uses that URL.

> bq. Does *withCheckout* exist? its referenced in this thread.

No, withCheckout does not exist. It was added to the scm step plugin [May 5, 2017|https://github.com/jenkinsci/workflow-scm-step-plugin/commit/bec924c64a8f19efbd7f6f08af9d879636dcf4e4] and then removed on [May 16, 2017|https://github.com/jenkinsci/workflow-scm-step-plugin/commit/dbcfe52ad81d16fe3dfdc5ce642f49720aff36e3].

> bq. Docs send you completely in the wrong direction unfortunately.

Which docs send you in the wrong direction?

nolange79@gmail.com (JIRA)

unread,

Feb 11, 2020, 11:21:06 AM2/11/20

to jenkinsc...@googlegroups.com

Norbert Lange commented on