[JIRA] (JENKINS-56854) ENV GIT_COMMIT is not match the right revision occasionally when using Jenkinsfile in GitHub

474 views
Skip to first unread message

hogerappa+jenkins@gmail.com (JIRA)

unread,
Apr 2, 2019, 11:26:03 AM4/2/19
to jenkinsc...@googlegroups.com
Satoshi Goto created an issue
 
Jenkins / Bug JENKINS-56854
ENV GIT_COMMIT is not match the right revision occasionally when using Jenkinsfile in GitHub
Issue Type: Bug Bug
Assignee: Unassigned
Components: github-branch-source-plugin
Created: 2019-04-02 15:25
Priority: Minor Minor
Reporter: Satoshi Goto

Problem Abstract

env GIT_COMMIT is not always same the real git revision in particular situation.

GIT_COMMIT, SHA of the current, is defined by Git Plugin.

Problem Detail

I use GitHub Branch Source Plugin to run Pull Request job with Jenkinsfile.

My job use Jenkinsfile in my github repository.

I found GIT_COMMIT is sometime different from real git revision in the stage of Pipeline.

 

When the problem happen, Jenkisn build logs says it causes git merge twice.

First merge is to read Jenkinsfile from git, second merge is to setup working directory.

So I print the revision in my Pipeline script.

env.GIT_COMMIT = 75ddc1933fd10b87c529536e3107ea7313debaea
HEAD revision = a98b709283bd47d251dfcc9360b91ffc024af16b

GIT_COMMIT is the revision at first merge, and HEAD is the revision at second merge.

How to reproduce this problem

I test with minimum condition which can reproduce the problem by using it↓

https://github.com/mtgto/jenkins-pipeline-test/blob/prtest/Jenkinsfile

https://github.com/mtgto/jenkins-pipeline-test/pull/1

 

The problem is only happened below all conditions matched:

  1. The job is Multibranch job.
  2. The job uses pipeline by Jenkinsfile in git repository.
  3. The pull request can't merge fast-forward.
  4. Twice merge commits is away at least one second.

1, 2: The condition to generate twice merge commits.

3: Fast-forward merge doesn't change by current time.

4: Git object contains time, it is by the second. Same time merge commits always have same revisions.

Installed Plugins

  • Apache HttpComponents Client 4.x API Plugin - 4.5.5-3.0
  • Authentication Tokens API Plugin - 1.3
  • bouncycastle API Plugin - 2.17
  • Branch API Plugin - 2.2.0
  • Command Agent Launcher Plugin - 1.3
  • Credentials Binding Plugin - 1.18
  • Credentials Plugin - 2.1.18
  • Display URL API - 2.3.1
  • Docker Commons Plugin - 1.13
  • Docker Pipeline - 1.17
  • Durable Task Plugin - 1.29
  • Folders Plugin - 6.7
  • Git client plugin - 2.7.6
  • Git plugin - 3.9.3
  • GIT server Plugin - 1.7
  • GitHub API Plugin - 1.95
  • GitHub Branch Source Plugin - 2.4.5
  • GitHub plugin - 1.29.4
  • Jackson 2 API Plugin - 2.9.8
  • JavaScript GUI Lib: ACE Editor bundle plugin - 1.1
  • JavaScript GUI Lib: Handlebars bundle plugin - 1.1.1
  • JavaScript GUI Lib: jQuery bundles (jQuery and jQuery UI) plugin - 1.2.1
  • JavaScript GUI Lib: Moment.js bundle plugin - 1.1.1
  • JDK Tool Plugin - 1.2
  • JSch dependency plugin - 0.1.55
  • JUnit Plugin - 1.27
  • Lockable Resources plugin - 2.5
  • Mailer Plugin - 1.23
  • Matrix Project Plugin - 1.14
  • Pipeline - 2.6
  • Pipeline Graph Analysis Plugin - 1.9
  • Pipeline: API - 2.33
  • Pipeline: Basic Steps - 2.15
  • Pipeline: Build Step - 2.8
  • Pipeline: Declarative - 1.3.7
  • Pipeline: Declarative Agent API - 1.1.1
  • Pipeline: Declarative Extension Points API - 1.3.7
  • Pipeline: Groovy - 2.65
  • Pipeline: Input Step - 2.10
  • Pipeline: Job - 2.32
  • Pipeline: Milestone Step - 1.3.1
  • Pipeline: Model API - 1.3.7
  • Pipeline: Multibranch - 2.21
  • Pipeline: Nodes and Processes - 2.29
  • Pipeline: REST API Plugin - 2.10
  • Pipeline: SCM Step - 2.7
  • Pipeline: Shared Groovy Libraries - 2.13
  • Pipeline: Stage Step - 2.3
  • Pipeline: Stage Tags Metadata - 1.3.7
  • Pipeline: Stage View Plugin - 2.10
  • Pipeline: Step API - 2.19
  • Pipeline: Supporting APIs - 3.2
  • Plain Credentials Plugin - 1.5
  • SCM API Plugin - 2.4.0
  • Script Security Plugin - 1.56
  • SSH Credentials Plugin - 1.15
  • Structs Plugin - 1.17
  • Token Macro Plugin - 2.7
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

hogerappa+jenkins@gmail.com (JIRA)

unread,
Apr 2, 2019, 11:27:02 AM4/2/19
to jenkinsc...@googlegroups.com

hogerappa+jenkins@gmail.com (JIRA)

unread,
Apr 2, 2019, 11:47:02 AM4/2/19
to jenkinsc...@googlegroups.com
Satoshi Goto updated an issue
h3. Problem Abstract


env GIT_COMMIT is not always same the real git revision in particular situation.

GIT_COMMIT, SHA of the current, is defined by [Git Plugin|https://wiki.jenkins.io/display/JENKINS/Git+Plugin].
h3. Problem Detail

I use [GitHub Branch Source Plugin|https://plugins.jenkins.io/github-branch-source] to run Pull Request job with Jenkinsfile.


My job use Jenkinsfile in my github repository.

I found GIT_COMMIT is sometime different from real git revision in the stage of Pipeline.

 

When the problem happen, Jenkisn build logs says it causes git merge twice.

First merge is to read Jenkinsfile from git, second merge is to setup working directory.

So I print the revision in my Pipeline script.

env.GIT_COMMIT = 75ddc1933fd10b87c529536e3107ea7313debaea
HEAD revision = a98b709283bd47d251dfcc9360b91ffc024af16b

GIT_COMMIT is the revision at first merge, and HEAD is the revision at second merge.
h3. How to reproduce this problem


I test with minimum condition which can reproduce the problem by using it↓

[https://github.com/mtgto/jenkins-pipeline-test/blob/prtest/Jenkinsfile]

[https://github.com/mtgto/jenkins-pipeline-test/pull/1]

 

The problem is only happened below all conditions matched:
# The job is Multibranch job.
# The job uses pipeline by Jenkinsfile in git repository.
# The pull request can't merge fast-forward.
# Twice merge commits is away at least one second.


1, 2: The condition to generate twice merge commits.

3: Fast-forward merge doesn't change by current time.

4: Git object contains time, it is by the second. Same time merge commits always have same revisions.
h3 h4 . Environments

I use Jenkins 2.164.1 in Docker container.

 
{noformat}
$ docker run -d --name jenkins -p 8080:8080 --name jenkins -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-alpine{noformat}
 
h5.
Installed Plugins
* Apache HttpComponents Client 4.x API Plugin - 4.5.5-3.0
* Authentication Tokens API Plugin - 1.3
* bouncycastle API Plugin - 2.17
* Branch API Plugin - 2.2.0
* Command Agent Launcher Plugin - 1.3
* Credentials Binding Plugin - 1.18
* Credentials Plugin - 2.1.18
* Display URL API - 2.3.1
* Docker Commons Plugin - 1.13
* Docker Pipeline - 1.17
* Durable Task Plugin - 1.29
* Folders Plugin - 6.7
* Git client plugin - 2.7.6
* Git plugin - 3.9.3
* GIT server Plugin - 1.7
* GitHub API Plugin - 1.95
* GitHub Branch Source Plugin - 2.4.5
* GitHub plugin - 1.29.4
* Jackson 2 API Plugin - 2.9.8
* JavaScript GUI Lib: ACE Editor bundle plugin - 1.1
* JavaScript GUI Lib: Handlebars bundle plugin - 1.1.1
* JavaScript GUI Lib: jQuery bundles (jQuery and jQuery UI) plugin - 1.2.1
* JavaScript GUI Lib: Moment.js bundle plugin - 1.1.1
* JDK Tool Plugin - 1.2
* JSch dependency plugin - 0.1.55
* JUnit Plugin - 1.27
* Lockable Resources plugin - 2.5
* Mailer Plugin - 1.23
* Matrix Project Plugin - 1.14
* Pipeline - 2.6
* Pipeline Graph Analysis Plugin - 1.9
* Pipeline: API - 2.33
* Pipeline: Basic Steps - 2.15
* Pipeline: Build Step - 2.8
* Pipeline: Declarative - 1.3.7
* Pipeline: Declarative Agent API - 1.1.1
* Pipeline: Declarative Extension Points API - 1.3.7
* Pipeline: Groovy - 2.65
* Pipeline: Input Step - 2.10
* Pipeline: Job - 2.32
* Pipeline: Milestone Step - 1.3.1
* Pipeline: Model API - 1.3.7
* Pipeline: Multibranch - 2.21
* Pipeline: Nodes and Processes - 2.29
* Pipeline: REST API Plugin - 2.10
* Pipeline: SCM Step - 2.7
* Pipeline: Shared Groovy Libraries - 2.13
* Pipeline: Stage Step - 2.3
* Pipeline: Stage Tags Metadata - 1.3.7
* Pipeline: Stage View Plugin - 2.10
* Pipeline: Step API - 2.19
* Pipeline: Supporting APIs - 3.2
* Plain Credentials Plugin - 1.5
* SCM API Plugin - 2.4.0
* Script Security Plugin - 1.56
* SSH Credentials Plugin - 1.15
* Structs Plugin - 1.17
* Token Macro Plugin - 2.7

hogerappa+jenkins@gmail.com (JIRA)

unread,
Apr 2, 2019, 8:26:02 PM4/2/19
to jenkinsc...@googlegroups.com
Satoshi Goto updated an issue
h3. Problem Abstract

env GIT_COMMIT is not always same the real git revision in particular situation.

Before pipeline stage begin, two merge commits generated by plugins.

It is the reason why the revision doesn't match
GIT_COMMIT .

 

GIT_COMMIT
, SHA of the current, is defined by [Git Plugin|https://wiki.jenkins.io/display/JENKINS/Git+Plugin].

h3. Problem Detail

I use [GitHub Branch Source Plugin|https://plugins.jenkins.io/github-branch-source] to run Pull Request job with Jenkinsfile.

My job use Jenkinsfile in my github repository.

I found GIT_COMMIT is sometime different from real git revision in the stage of Pipeline.

 

When the problem happen, Jenkisn build logs says it causes git merge twice.

First merge is to read Jenkinsfile from git, second merge is to setup working directory.

So I print the revision in my Pipeline script.

env.GIT_COMMIT = 75ddc1933fd10b87c529536e3107ea7313debaea
HEAD revision = a98b709283bd47d251dfcc9360b91ffc024af16b

GIT_COMMIT is the revision at first merge, and HEAD is the revision at second merge.
h3. How to reproduce this problem

I test with minimum condition which can reproduce the problem by using it↓

[https://github.com/mtgto/jenkins-pipeline-test/blob/prtest/Jenkinsfile]

[https://github.com/mtgto/jenkins-pipeline-test/pull/1]

 

The problem is only happened below all conditions matched:
# The job is Multibranch job.
# The job uses pipeline by with Jenkinsfile in git repository.

# The pull request can't merge fast-forward.
# Twice merge commits is away at least one second.

1, 2: The condition to generate twice merge commits.

3: Fast-forward merge doesn't change the revision by current time.


4: Git object contains time, it is by the second. Same time merge commits always have same revisions.
h4. Environments

I use Jenkins 2.164.1 in Docker container
to reproduce this problem .

hogerappa+jenkins@gmail.com (JIRA)

unread,
Apr 2, 2019, 8:30:03 PM4/2/19
to jenkinsc...@googlegroups.com
Satoshi Goto updated an issue
h3. Problem Abstract

env GIT_COMMIT is not always same the real git revision in particular situation.

Before pipeline stage begin, two merge commits generated by plugins.

It is the reason why the revision doesn't match GIT_COMMIT.

 

GIT_COMMIT, SHA of the current, is defined by [Git Plugin|https://wiki.jenkins.io/display/JENKINS/Git+Plugin].

h3. Problem Detail

I use [GitHub Branch Source Plugin|https://plugins.jenkins.io/github-branch-source] to run Pull Request job with Jenkinsfile.

My job use Jenkinsfile in my github repository.

I found GIT_COMMIT is sometime different from real git revision in the stage of Pipeline.

 

When the problem happen, Jenkisn build logs says it causes git merge twice.

First merge is to read Jenkinsfile from git, second merge is to setup working directory.

So I print the revision in my Pipeline script.

env.GIT_COMMIT = 75ddc1933fd10b87c529536e3107ea7313debaea
HEAD revision = a98b709283bd47d251dfcc9360b91ffc024af16b

GIT_COMMIT is the revision at first merge, and HEAD is the revision at second merge.
h3. How to reproduce this problem

I test with minimum condition which can reproduce the problem by using it↓

[https://github.com/mtgto/jenkins-pipeline-test/blob/prtest/Jenkinsfile]

[https://github.com/mtgto/jenkins-pipeline-test/pull/1]

 

The problem is only happened below all conditions matched:
# The job is Multibranch job.
# The job uses pipeline with Jenkinsfile in git repository.

# The pull request can't merge fast-forward.
# Twice Two merge commits is away at least one second.


1, 2: The condition to generate twice merge commits.

3: Fast-forward merge doesn't change the revision by time.

4: Git object contains time, it is
changed by the second. Same time merge commits always have same revisions.

h4. Environments

I use Jenkins 2.164.1 in Docker container to reproduce this problem.

 
{noformat}
$ docker run -d --name jenkins -p 8080:8080 --name jenkins -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-alpine{noformat}
 
I install two plugins while first setup:
* [GitHub Branch Source|https://plugins.jenkins.io/github-branch-source]
* [Pipeline|https://plugins.jenkins.io/workflow-aggregator]

bitwiseman@gmail.com (JIRA)

unread,
May 9, 2019, 8:42:08 PM5/9/19
to jenkinsc...@googlegroups.com
Liam Newman commented on Bug JENKINS-56854
 
Re: ENV GIT_COMMIT is not match the right revision occasionally when using Jenkinsfile in GitHub

The way I understand it, is that non-fast-forward cases will always have a merge commit. The GIT_COMMIT will be the sha1 of that merge commit. If you want to test this, try this scenario on two different agents. In that case GIT_COMMIT will be different on each agent by-design.

In older freestyle jobs GIT_COMMIT was equal to the head commit. If you want that to be the case again you can change the configuration of your pipeline to used the source branch head instead of merging. However, that also means you won't be testing the merged state.

bitwiseman@gmail.com (JIRA)

unread,
May 9, 2019, 8:43:02 PM5/9/19
to jenkinsc...@googlegroups.com
Liam Newman edited a comment on Bug JENKINS-56854

hogerappa+jenkins@gmail.com (JIRA)

unread,
May 10, 2019, 6:39:02 AM5/10/19
to jenkinsc...@googlegroups.com

Thanks Liam Newman. My explanation is very sad, sorry.

In fact, I came out ahead this problem by not using GIT_COMMIT.
I abandon GIT_COMMIT because I DO want to test the revision which pull request merged.

I run Jenkins by using Git Plugin in debug mode, so I figure out older GIT_COMMIT is set.
But I don't find which plugin is wrong...

hogerappa+jenkins@gmail.com (JIRA)

unread,
May 10, 2019, 6:43:03 AM5/10/19
to jenkinsc...@googlegroups.com
Satoshi Goto updated an issue
Change By: Satoshi Goto
# Two merge commits is away at least one second.


1, 2: The condition to generate twice merge commits.

3: Fast-forward merge doesn't change the revision by time.

4: First commit is created at fetching Jenkinsfile. Second commit is created at fetching whole target repository. Git object contains time, it is changed by the second. Same time merge commits always have same revisions.

bitwiseman@gmail.com (JIRA)

unread,
May 29, 2019, 2:31:01 PM5/29/19
to jenkinsc...@googlegroups.com
Liam Newman commented on Bug JENKINS-56854
 
Re: ENV GIT_COMMIT is not match the right revision occasionally when using Jenkinsfile in GitHub

Running in debug mode is definitely a hack.
My point is that this is a reasonable feature enhancement request - to add more environment variables for pull requests, but this is expected behavior for the current version.

hogerappa+jenkins@gmail.com (JIRA)

unread,
May 29, 2019, 10:41:02 PM5/29/19
to jenkinsc...@googlegroups.com

hogerappa+jenkins@gmail.com (JIRA)

unread,
May 29, 2019, 10:42:02 PM5/29/19
to jenkinsc...@googlegroups.com

but this is expected behavior for the current version.

Okay. I closed this issue.

Reply all
Reply to author
Forward
0 new messages