[JIRA] (JENKINS-45489) checkout(scm) step can return wrong variables when used following another Git checkout

728 views
Skip to first unread message

mark@kakapo.co.nz (JIRA)

unread,
Jul 4, 2018, 9:22:02 PM7/4/18
to jenkinsc...@googlegroups.com
Mark Wright updated an issue
 
Jenkins / Bug JENKINS-45489
checkout(scm) step can return wrong variables when used following another Git checkout
Change By: Mark Wright
Summary: checkout(scm) step can return wrong variables when used with a global library that is pulled from following another Git checkout
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

mark@kakapo.co.nz (JIRA)

unread,
Jul 4, 2018, 9:43:03 PM7/4/18
to jenkinsc...@googlegroups.com
Mark Wright edited a comment on Bug JENKINS-45489
 
Re: checkout(scm) step can return wrong variables when used following another Git checkout
The issue is repeatable without involving shared-libraries. Simply having an SCM pipeline script which checks out a different revision to that used to load the pipeline sciprt. The {{checkout}} step  returns the GIT_COMMIT of the original checkout and not the new checkout.


I've also seen this manifested in my multibranch pipeline jobs, but it is best demonstrated by a simple parameterised pipeline.   


Create a Pipeline job configured with "{{refs/heads/master}}" as the branch specifier. Give the job a single "TAG" parameter, providing a tag to be checked out by the pipeline. Use this script:

{code
:groovy }
pipeline
{
    agent any
    environment
    {
        git_tool = tool(name: 'Default', type: 'git')
    }
    options
    {
        skipDefaultCheckout()
    }
    stages
    {
        stage('Checkout')
        {
            steps
            {
                script
                {
                    def buildTag = env.TAG
                    echo "Building against tag '${buildTag}'"

                    def newScm = [$class: 'GitSCM', userRemoteConfigs: scm.userRemoteConfigs, branches: [[name: "refs/tags/${buildTag}"]]]

                    def checkoutDetails = checkout scm: newScm, poll: false, changelog: false

                    echo "checkout scm returned SHA = ${checkoutDetails.GIT_COMMIT}"
                    bat """git status"""
                }
            }
        }
    }
}
{code}

When run with a tag at the HEAD tip of the specified branch (master) we see the returned SHA is as expected:

{code: java }
Building against tag 'tag3'
[Pipeline] checkout
> C:\Program Files\Git\cmd\git.exe rev-parse --is-inside-work-tree # timeout=120
Fetching changes from the remote Git repository
> C:\Program Files\Git\cmd\git.exe config remote.origin.url g...@github.aus.thenational.com:P640806/jenkins_testing.git # timeout=120
Fetching upstream changes from g...@github.aus.thenational.com:P640806/jenkins_testing.git
> C:\Program Files\Git\cmd\git.exe --version # timeout=120
using GIT_SSH to set credentials
> C:\Program Files\Git\cmd\git.exe fetch --tags --progress g...@github.aus.thenational.com:P640806/jenkins_testing.git +refs/heads/*:refs/remotes/origin/*
> C:\Program Files\Git\cmd\git.exe rev-parse "refs/tags/tag3^{commit}" # timeout=120
> C:\Program Files\Git\cmd\git.exe rev-parse "refs/remotes/origin/refs/tags/tag3^{commit}" # timeout=120
Checking out Revision e03409cea735e7353e421551c6bd5963f436c38a (refs/tags/tag3)
> C:\Program Files\Git\cmd\git.exe config core.sparsecheckout # timeout=120
> C:\Program Files\Git\cmd\git.exe checkout -f e03409cea735e7353e421551c6bd5963f436c38a
Commit message: "Removed env.GIT_COMMIT usage"
[Pipeline] echo
checkout scm returned SHA = e03409cea735e7353e421551c6bd5963f436c38a
[Pipeline] bat
[test_scm_issue] Running batch script

d:\jenkins\ws\test_scm_issue>git status
HEAD detached at e03409c
nothing to commit, working tree clean
{code}

If an additional commit is added to master (so the tag is no longer at the HEAD), we see the correct revision (e03409c) is checked out, however the revision state returned by the checkout step is the new HEAD tip of master (5e70b9e903582cd1055e60b819c6f2f09f01aee7):

{code: java }
Building against tag 'tag3'
[Pipeline] checkout
> C:\Program Files\Git\cmd\git.exe rev-parse --is-inside-work-tree # timeout=120
Fetching changes from the remote Git repository
> C:\Program Files\Git\cmd\git.exe config remote.origin.url g...@github.aus.thenational.com:P640806/jenkins_testing.git # timeout=120
Fetching upstream changes from g...@github.aus.thenational.com:P640806/jenkins_testing.git
> C:\Program Files\Git\cmd\git.exe --version # timeout=120
using GIT_SSH to set credentials
> C:\Program Files\Git\cmd\git.exe fetch --tags --progress g...@github.aus.thenational.com:P640806/jenkins_testing.git +refs/heads/*:refs/remotes/origin/*
> C:\Program Files\Git\cmd\git.exe rev-parse "refs/tags/tag3^{commit}" # timeout=120
> C:\Program Files\Git\cmd\git.exe rev-parse "refs/remotes/origin/refs/tags/tag3^{commit}" # timeout=120
Checking out Revision e03409cea735e7353e421551c6bd5963f436c38a (refs/tags/tag3)
> C:\Program Files\Git\cmd\git.exe config core.sparsecheckout # timeout=120
> C:\Program Files\Git\cmd\git.exe checkout -f e03409cea735e7353e421551c6bd5963f436c38a
Commit message: "Removed env.GIT_COMMIT usage"
[Pipeline] echo
checkout scm returned SHA = 5e70b9e903582cd1055e60b819c6f2f09f01aee7
[Pipeline] bat
[test_scm_issue] Running batch script

d:\jenkins\ws\test_scm_issue>git status
HEAD detached at e03409c
nothing to commit, working tree clean
{code}

mark@kakapo.co.nz (JIRA)

unread,
Jul 5, 2018, 5:10:03 PM7/5/18
to jenkinsc...@googlegroups.com
Mark Wright edited a comment on Bug JENKINS-45489
The issue is repeatable without involving shared-libraries. Simply by having an SCM pipeline script which checks out a different revision to that used to load the pipeline sciprt. The {{checkout}} step returns the GIT_COMMIT of the original checkout and not the new checkout.


I've also seen this manifested in my multibranch pipeline jobs, but it is best demonstrated by a simple parameterised pipeline.

Create a Pipeline job configured with "{{refs/heads/master}}" as the branch specifier. Give the job a single "TAG" parameter, providing a tag to be checked out by the pipeline. Use this script:
{code :java }

pipeline
{
    agent any
    environment
    {
        git_tool = tool(name: 'Default', type: 'git')
    }
    options
    {
        skipDefaultCheckout()
    }
    stages
    {
        stage('Checkout')
        {
            steps
            {
                script
                {
                    def buildTag = env.TAG
                    echo "Building against tag '${buildTag}'"

                    def newScm = [$class: 'GitSCM', userRemoteConfigs: scm.userRemoteConfigs, branches: [[name: "refs/tags/${buildTag}"]]]

                    def checkoutDetails = checkout scm: newScm, poll: false, changelog: false

                    echo "checkout scm returned SHA = ${checkoutDetails.GIT_COMMIT}"
                    bat """git status"""
                }
            }
        }
    }
}
{code}
When run with a tag at the tip of the specified branch (master) we see the returned SHA is as expected:

{code:java}
Building against tag 'tag3'
[Pipeline] checkout
> C:\Program Files\Git\cmd\git.exe rev-parse --is-inside-work-tree # timeout=120
Fetching changes from the remote Git repository
> C:\Program Files\Git\cmd\git.exe config remote.origin.url g...@github.aus.thenational.com:P640806/jenkins_testing.git # timeout=120
Fetching upstream changes from g...@github.aus.thenational.com:P640806/jenkins_testing.git
> C:\Program Files\Git\cmd\git.exe --version # timeout=120
using GIT_SSH to set credentials
> C:\Program Files\Git\cmd\git.exe fetch --tags --progress g...@github.aus.thenational.com:P640806/jenkins_testing.git +refs/heads/*:refs/remotes/origin/*
> C:\Program Files\Git\cmd\git.exe rev-parse "refs/tags/tag3^{commit}" # timeout=120
> C:\Program Files\Git\cmd\git.exe rev-parse "refs/remotes/origin/refs/tags/tag3^{commit}" # timeout=120
Checking out Revision e03409cea735e7353e421551c6bd5963f436c38a (refs/tags/tag3)
> C:\Program Files\Git\cmd\git.exe config core.sparsecheckout # timeout=120
> C:\Program Files\Git\cmd\git.exe checkout -f e03409cea735e7353e421551c6bd5963f436c38a
Commit message: "Removed env.GIT_COMMIT usage"
[Pipeline] echo
checkout scm returned SHA = e03409cea735e7353e421551c6bd5963f436c38a
[Pipeline] bat
[test_scm_issue] Running batch script

d:\jenkins\ws\test_scm_issue>git status
HEAD detached at e03409c
nothing to commit, working tree clean
{code}
If an additional commit is added to master (so the tag is no longer at the HEAD tip ), we see the correct revision (e03409c) is checked out, however the revision state returned by the checkout step is the new tip of master (5e70b9e903582cd1055e60b819c6f2f09f01aee7):

richard.bowater@gmail.com (JIRA)

unread,
Mar 29, 2019, 10:37:04 AM3/29/19
to jenkinsc...@googlegroups.com

I've just run up against this too.

```


Fetching changes from the remote Git repository

Fetching without tags
Checking out Revision 5cc3005a298d50fa0c2bc919293fcf3b3ed936de (print-env)
Commit message: "Print more env"

GIT_COMMIT=eb65cd4f46c828362429cbbd2d904f114bb4b801
GIT_BRANCH=master
```

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

richard.bowater@gmail.com (JIRA)

unread,
Mar 29, 2019, 10:38:03 AM3/29/19
to jenkinsc...@googlegroups.com
Richard Bowater edited a comment on Bug JENKINS-45489
I've just run up against this too.

``` {code}
Fetching changes from the remote Git repository
Fetching without tags
Checking out Revision 5cc3005a298d50fa0c2bc919293fcf3b3ed936de (print-env)
Commit message: "Print more env"

GIT_COMMIT=eb65cd4f46c828362429cbbd2d904f114bb4b801
GIT_BRANCH=master
``` {code}

richard.bowater@gmail.com (JIRA)

unread,
Mar 29, 2019, 10:39:01 AM3/29/19
to jenkinsc...@googlegroups.com
Richard Bowater edited a comment on Bug JENKINS-45489
I've just run up against this too.

{code}
Fetching changes from the remote Git repository
Fetching without tags
Checking out Revision 5cc3005a298d50fa0c2bc919293fcf3b3ed936de (print-env)
Commit message: "Print more env"

GIT_COMMIT=eb65cd4f46c828362429cbbd2d904f114bb4b801
GIT_BRANCH=master
{code}


Doesn't seem to be an obvious way to work around it?

richard.bowater@gmail.com (JIRA)

unread,
Mar 29, 2019, 10:41:02 AM3/29/19
to jenkinsc...@googlegroups.com
Richard Bowater edited a comment on Bug JENKINS-45489
I've just run up against this too.

{code}
Fetching changes from the remote Git repository
Fetching without tags
Checking out Revision 5cc3005a298d50fa0c2bc919293fcf3b3ed936de (print-env)
Commit message: "Print more env"

GIT_COMMIT=eb65cd4f46c828362429cbbd2d904f114bb4b801
GIT_BRANCH=master
{code}

Doesn't seem to be an obvious way to work around it? My particular use case is:

* a global shared library configured to checkout from git
* a multibranch pipeline configured to load Jenkinsfiles from the shared libraries above

We're using pipelines to build and test shared libraries before deployment, but branch builds are being unpredictable due to the environment variables being incorrect.

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

unread,
Mar 29, 2019, 11:01:05 AM3/29/19
to jenkinsc...@googlegroups.com

Richard Bowater the most direct work around is to compute the SHA1 of the working directory with a call to a shell script, batch script, or powershell script. Refer to the[ example in a stackoverflow article|https://stackoverflow.com/questions/45236824/get-git-commit-sha-in-jenkins-pipeline].

The technique is also in the pipeline script utilities that I use.

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

unread,
Mar 29, 2019, 11:01:05 AM3/29/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-45489
[~rjbwtr] the most direct work around is to compute the SHA1 of the working directory with a call to a shell script, batch script, or powershell script.  Refer to the[ example in a stackoverflow article|https://stackoverflow.com/questions/45236824/get-git-commit-sha-in-jenkins-pipeline].

The technique is also in the [pipeline script utilities|https://github.com/MarkEWaite/jenkins-pipeline-utils/blob/ff4ba450a69ff158274b72b600bf5e1364bcc57c/src/com/markwaite/Build.groovy#L39] that I use.

mark@kakapo.co.nz (JIRA)

unread,
Apr 2, 2019, 2:31:02 PM4/2/19
to jenkinsc...@googlegroups.com

Richard Bowater, on (Windows) build-server, we use the following in our scripts as Mark Waite suggests:

def sha = bat(returnStdout: true, script: '@git rev-parse HEAD').trim() 
Reply all
Reply to author
Forward
0 new messages