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:
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"""
}
}
}
}
}
When run with a tag at the tip of the specified branch (master) we see the returned SHA is as expected:
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 git@github.aus.thenational.com:P640806/jenkins_testing.git # timeout=120
Fetching upstream changes from git@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 git@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
If an additional commit is added to master (so the tag is no longer at the 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):
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 git@github.aus.thenational.com:P640806/jenkins_testing.git # timeout=120
Fetching upstream changes from git@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 git@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
I can confirm that I'm seeing this with git-plugin 3.5.0 and jenkins 2.60.2 and it seems to be pretty consistent on a particular pipeline job, where I have now replayed the job 10 times with the same output.
I don't see any indication that the variables are mixed between both repositories, all of them seem to be from the one I import the "library" from.
In my setup I have a jenkinsfile from a repository which includes a "library" file from the same repository, through the usage of fileloader.withGit. The actual code that I'm building/testing and am checking out with checkout step is a second repository.