[JIRA] (JENKINS-57371) error message when building PR

error message when building PR

Issue Type:	Bug
Assignee:	Unassigned
Components:	github-branch-source-plugin
Created:	2019-05-08 13:13
Priority:	Major
Reporter:	Niklas Claesson

Hi,

After updating to the latest version (2.5.1) I get the following error messages immediately and the build fails.

ERROR: Invalid merge hash for pull request 522 : Head and base commits do match merge commit a538d719213e99bb52dc73c2fac2fd3b1375ee1d+7b4572c5176951887e3fd3cf80df30821caed9ec (8f660b9de0bb201869379a428d117866539f4cce)
Finished: FAILURE

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

bitwiseman@gmail.com (JIRA)

unread,

May 8, 2019, 9:35:02 PM5/8/19

to jenkinsc...@googlegroups.com

Liam Newman assigned an issue to Liam Newman

Jenkins /

error message when building PR

Change By:	Liam Newman
Assignee:	Liam Newman

bitwiseman@gmail.com (JIRA)

unread,

May 8, 2019, 9:35:02 PM5/8/19

to jenkinsc...@googlegroups.com

Liam Newman commented on

Niklas Claesson
The message indicate that the merge commit for this PR has parents other than commits that are at the head of the source and target branches.

Please upgrade to 2.5.2 (just released). While it will probably get the same result, but the output maybe different.

Is this an older PR?
(If public) What repo is this on?
what is the result from https://api.github.com/repos/YOURORG/YOURREPO/commits/8f660b9de0bb201869379a428d117866539f4cce

Are you getting this message for multiple PRs?
Does this happen after you run a scan?

nicke.claesson@gmail.com (JIRA)

unread,

May 9, 2019, 5:37:02 AM5/9/19

to jenkinsc...@googlegroups.com

Niklas Claesson commented on

Right now I'm a little bit hesitant to update again because last time this issue occurred and broke our CI.

It was a PR from a fork of a private repo. And I tried opening multiple PRs with all the same issue.

I didn't try to rescan the repository. Is that necessary every time I update the plugin?

bitwiseman@gmail.com (JIRA)

unread,

May 9, 2019, 12:21:02 PM5/9/19

to jenkinsc...@googlegroups.com

Liam Newman commented on

Niklas Claesson
I certainly don't want you to break your CI, but there isn't enough information here to be able to debug this.
Can you answer the questions above?
If you'd rather chat on gitter.im, we can do that too.

bitwiseman@gmail.com (JIRA)

unread,

May 9, 2019, 1:29:03 PM5/9/19

to jenkinsc...@googlegroups.com

Liam Newman edited a comment on

[~nickez]

I certainly don't want you to break your CI, but there isn't enough information here to be able to debug this.

Can you answer the questions above?

Did you say you tried closing and reopening? When you did that were the commit sha values different after close and reopen?

If you'd rather chat on https:// gitter.im /bitwiseman (or some other chat platform) , we can do that too.

bitwiseman@gmail.com (JIRA)

unread,

May 9, 2019, 1:39:02 PM5/9/19

to jenkinsc...@googlegroups.com

Liam Newman edited a comment on

[~nickez]
I certainly don't want you to break your CI, but there isn't enough information here to be able to debug this.

Can you answer the questions above?
Did you say you tried closing and reopening? When you did that were the commit sha values different after close and reopen?

For each of the sha values in that error line I need to see the result of the following:
what is the result from this api query:
If https://api.github.com/repos/YOURORG/YOURREPO/commits/COMMITSHA

I could also use the info from:
https://api.github.com/repos/YOURORG/YOURREPO/pulls/PULLNUMBER

For a private repo, you' ll need pass credentials or an api key to access these.

It would bIf you' d rather chat on https://gitter.im/bitwiseman (or some other chat platform), we can do that too.

bitwiseman@gmail.com (JIRA)

unread,

May 9, 2019, 1:51:02 PM5/9/19

to jenkinsc...@googlegroups.com

Liam Newman edited a comment on

[~nickez]
I certainly don't want you to break your CI, but there isn't enough information here to be able to debug this.

The rescan is not generally needed, I'm just trying to get more information and see if there's a reasonable workaround.

Can To explain more fully: this failure occurs when the plugin detects that the merge_commit_sha provided by github is not the immediate child of the head commit of the source branch and the head commit of the base branch. This can happen when the base branch is updated after the PR job is queued but before the PR starts. Usually that would mean another PR job is also queued after this one and it will have consistent values and run successfully.

Questions:
So, this also happened on new PR's that you answer opened after the questions above upgrade ?

Are you doing anything of note to your repo as you start PRs?

Did you say you tried closing and reopening? When you did that were the commit sha values different after close and reopen?

For each of the sha values in that error line I need to see the result of the following:
what is the result from this api query:

https://api.github.com/repos/YOURORG/YOURREPO/commits/COMMITSHA

I could also use the info from:
https://api.github.com/repos/YOURORG/YOURREPO/pulls/PULLNUMBER

For a private repo, you'll need pass credentials or an api key to access these.

It would bIf you'd rather chat on https://gitter.im/bitwiseman (or some other chat platform), we can do that too.

bitwiseman@gmail.com (JIRA)

unread,

May 9, 2019, 2:04:02 PM5/9/19

to jenkinsc...@googlegroups.com

Liam Newman edited a comment on

[~nickez]
I certainly don't want you to break your CI, but there isn't enough information here to be able to debug this.

The rescan is not generally needed, I'm just trying to get more information and see if there's a reasonable workaround.

To explain more fully: this failure occurs when the plugin detects that the merge_commit_sha provided by github is not the immediate child of the head commit of the source branch and the head commit of the base branch.    This can happen when the base branch is updated after the PR job is queued but before the PR starts.  Usually that would mean another PR job is also queued after this one and it will have consistent values and run successfully.   It is a safety measure to ensure accurate CI runs.

That fact that you're getting this (even on new PRs) indicates something is changing the commit structure (or at least that Jenkins believes they are changing).

This definitely is not happening to everyone - 2.5.1 was confirmed to work by several reporters of a previous regression.  So, there's something different about your configuration. We need to figure out what that is before we can address/fix it.

Questions:
So Is this happen on jobs triggered by webhook?
What happens when you do a scan of the repo?  (Can you provide the scan log?)
For an open PR , what happens when you manually run the pipeline job?
(Double checking) Did this also happened error happen on new PR's that you opened after the upgrade?

Are you doing anything of note to your repo (pushing or amending commits) as you start PRs?
Did you say you
(Double checking)You tried closing and reopening the PR on GitHub ? When you did that were the commit sha values in the error different after close and reopen?

For each of the sha values in that error line I need to see the result of the following:
what is the result from this api query:
https://api.github.com/repos/YOURORG/YOURREPO/commits/COMMITSHA

I could also use the info from:
https://api.github.com/repos/YOURORG/YOURREPO/pulls/PULLNUMBER

For a private repo, you'll need pass credentials or an api key to access these.

It would bIf If you'd rather chat on https://gitter.im/bitwiseman (or some other chat platform), we can do that too.

bls737@gmail.com (JIRA)

unread,

May 10, 2019, 5:09:01 AM5/10/19

to jenkinsc...@googlegroups.com

Brandon Le Sann commented on

I had the exact same issue as Niklas Claesson .

Closing and reopening the PR did not work. Creating new different PRs still produced the same error (although with different hash values).

Ignoring this error message and merging the PR solved the issue and doesn't seem to appear again...

Hope it helps.

bitwiseman@gmail.com (JIRA)

unread,

May 10, 2019, 2:17:03 PM5/10/19

to jenkinsc...@googlegroups.com

Liam Newman commented on

Brandon Le Sann

Ignoring this error message and merging the PR solved the issue and doesn't seem to appear again...

What do you mean here? Once you merge one PR the rest of the PRs work okay from then on? Could you be a bit more specific?

nicke.claesson@gmail.com (JIRA)

unread,

May 13, 2019, 5:41:02 AM5/13/19

to jenkinsc...@googlegroups.com

Niklas Claesson commented on

I updated to 2.5.2 and cannot reproduce this issue any more. Thanks!

bls737@gmail.com (JIRA)

unread,

May 13, 2019, 8:55:02 AM5/13/19

to jenkinsc...@googlegroups.com

Brandon Le Sann commented on

Liam Newman , yes, once the PR was merged the next PRs worked fine.

Once you merge one PR the rest of the PRs work okay from then on?

exactly. When the first PR was merged, the other PRs were rebuilt and were no longer throwing this error.

And while this error was still present, the build of the other branches worked fine. It was just the PRs failing.

bitwiseman@gmail.com (JIRA)

unread,

May 13, 2019, 4:36:01 PM5/13/19

to jenkinsc...@googlegroups.com

Liam Newman commented on

Niklas Claesson
Excellent!

Brandon Le Sann
Yes, the only changes in 2.5.x were ones that changed the way PRs were handled. So, branches not being effected makes sense.
The behavior you're seeing is truly odd. But if it is all clear now, that is the important part.

I'm going to leave this open in case there are other who see upgrade issues to v2.5.2.

audun.halland@gmail.com (JIRA)

unread,

May 16, 2019, 7:54:02 AM5/16/19

to jenkinsc...@googlegroups.com

Audun Halland commented on

This also happens to us. I'm getting error message:
ERROR: Invalid merge hash for pull request 47 : Head and base commits do match merge commit 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (98e8973772d6f2075ea775f7e985e0a739e3fc34)
Finished: FAILURE.

5729 is the tip of the PR branch. 7e88 is the commit of the previously merged PR (onto master). However, our pipeline generates and pushes a release commit to github for the master job, where it updates the version number of the app, and tags that commit with the release number. This commit is set up to be ignored by jenkins (using Ignore Committer Strategy). So, the current tip of master branch is not 7e88 anymore, and I suspect that this has something to do with this problem.

audun.halland@gmail.com (JIRA)

unread,

May 16, 2019, 8:58:02 AM5/16/19

to jenkinsc...@googlegroups.com

Audun Halland commented on

However, I also found that "Scan Repository Now" does not see the pull request as updated, even if the tip of the PR branch is a merge that points to latest master. Log outputs:

Getting remote branches...

Checking branch master

Getting remote pull requests...
‘Jenkinsfile’ found
Met criteria
No changes detected: master (still at 76ff9c62d27d6b60666c08d0686e3100974fd1fe)

....

Checking pull request #47
‘Jenkinsfile’ found
Met criteria
No changes detected: PR-47 (still at 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (98e8973772d6f2075ea775f7e985e0a739e3fc34))

Current master is 76ff, so the PR checker should not have tried to use 5729+7e88, but 5729+76ff. Question remains whether this is misinformation from github, or incorrect logic in github-branch-source.

audun.halland@gmail.com (JIRA)

unread,

May 16, 2019, 9:14:03 AM5/16/19

to jenkinsc...@googlegroups.com

Audun Halland edited a comment on

However, I also found that "Scan Repository Now" does not see the pull request as updated, even if the tip of the PR branch is a merge that points to latest master. Log outputs:

Getting remote branches...

Checking branch master

Getting remote pull requests...
‘Jenkinsfile’ found
Met criteria
No changes detected: master (still at 76ff9c62d27d6b60666c08d0686e3100974fd1fe)

....

Checking pull request #47
‘Jenkinsfile’ found
Met criteria
No changes detected: PR-47 (still at 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (98e8973772d6f2075ea775f7e985e0a739e3fc34))

Current master is 76ff, so the PR checker should not have tried to use 5729+7e88, but 5729+76ff. Question remains whether this is misinformation from github, or incorrect logic in github-branch-source.

EDIT: PR strategy is "Merging the pull request with the current target branch revision".

bitwiseman@gmail.com (JIRA)

unread,

May 16, 2019, 3:45:03 PM5/16/19

to jenkinsc...@googlegroups.com

Liam Newman commented on

Audun Halland

This commit is set up to be ignored by jenkins (using Ignore Committer Strategy). So, the current tip of master branch is not 7e88 anymore, and I suspect that this has something to do with this problem.

This is extremely useful! This could be where the problem is coming from. It is definitely some kind of incorrect assumptions made by github-branch-source.

If you run the PR-47 job manually, using "Build Now" instead of via the scan, does the Pipeline run successfully?

Here's the problem:
The plugin needs to make sure that the base, source, and merge commits are in sync otherwise the master (which uses the merge_commit) could be looking at different information from other agents, which use the source+base to create a new merge on the local file system. From what you're describing, the ignore committer strategy forces plugin not to see the right base commit and so forces the commits out-of-sync.

The merge_commit behavior was introduced in 2.5.0 - I was unaware of the filter trait you've mentioned. I'm looking at it now.

bitwiseman@gmail.com (JIRA)

unread,

May 16, 2019, 4:29:03 PM5/16/19

to jenkinsc...@googlegroups.com

Liam Newman edited a comment on

[~audunhalland]
{quote} This commit is set up to be ignored by jenkins (using Ignore Committer Strategy). So, the current tip of master branch is not 7e88 anymore, and I suspect that this has something to do with this problem.{quote}

This is extremely useful! This could be where the problem is coming from. It is definitely some kind of incorrect assumptions made by github-branch-source.

If you run the PR-47 job manually, using "Build Now" instead of via the scan, does the Pipeline run successfully?

Here's the problem:
The plugin needs to make sure that the base, source, and merge commits are in sync otherwise the master (which uses the merge_commit) could be looking at different information from other agents, which use the source+base to create a new merge on the local file system. From what you're describing, the ignore committer strategy forces plugin not to see the right base commit and so forces the commits out-of-sync. :(

The merge_commit behavior was introduced in 2.5.0 - I was unaware of the filter trait you've mentioned. I'm looking at it now.

bitwiseman@gmail.com (JIRA)

unread,

May 16, 2019, 10:50:02 PM5/16/19

to jenkinsc...@googlegroups.com

Liam Newman commented on

Audun Halland
Wait a minute.

If you run the PR-47 job manually, using "Build Now" instead of via the scan, does the Pipeline run successfully?

Also, what happens if you close and reopen that PR while making sure no other change goes into master?

I think there are two different issues converging here:
1. If the update of master to the new PR is causing the pipeline to fail due to inconsistent commits
2. The Ignore committer strategy is then preventing the PR from being recognized as having been updated.

There are likely other strategies that will also cause this to fail.

Perhaps the right solution is to allow inconsistencies as long as the merge_commit is the child of two commits that are children of the two commits in the PR. I'm not especially happy with that though. It feels like it opens the door to possible problems.

I need to think about what the correct behavior should be in this case.

audun.halland@gmail.com (JIRA)

unread,

May 17, 2019, 4:31:02 AM5/17/19

to jenkinsc...@googlegroups.com

Audun Halland commented on

"Build now" is as broken as the webhook from github, disregarding Closing and re-opening the PR in github had no effect (although the PR was retained as a "disabled" Jenkins job in that meantime. I could try to delete it).

I can confirm that 7e88 is the first parent of master HEAD that is not ignored by Ignore Committer Strategy.

audun.halland@gmail.com (JIRA)

unread,

May 17, 2019, 4:31:03 AM5/17/19

to jenkinsc...@googlegroups.com

Audun Halland edited a comment on

"Build now" is as broken as the webhook(?) from github, disregarding Closing and re-opening the PR in github had no effect (although the PR was retained as a "disabled" Jenkins job in that meantime. I could try to delete it).

I can confirm that 7e88 is the first parent of master HEAD that is not ignored by Ignore Committer Strategy.

audun.halland@gmail.com (JIRA)

unread,

May 17, 2019, 4:31:03 AM5/17/19

to jenkinsc...@googlegroups.com

Audun Halland edited a comment on

"Build now" is as broken as the webhook( ? ) from github , disregarding . Closing and re-opening the PR in github had no effect (although the PR was retained as a "disabled" Jenkins job in that meantime. I could try to delete it).

I can confirm that 7e88 is the first parent of master HEAD that is not ignored by Ignore Committer Strategy.

audun.halland@gmail.com (JIRA)

unread,

May 17, 2019, 4:39:02 AM5/17/19

to jenkinsc...@googlegroups.com

Audun Halland edited a comment on

"Build now" is as broken as the webhook( ? ) from github. Closing and re-opening the PR in github had no effect (although the PR was retained as a "disabled" Jenkins job in that meantime. I could try to delete it).

I can confirm that 7e88 is the first parent of master HEAD that is not ignored by Ignore Committer Strategy. And it is the first one that is a merge commit (a merge of the previous PR). The commits (two, in fact) at the tip of master, generated by jenkins, are regular commits.

bitwiseman@gmail.com (JIRA)

unread,

May 17, 2019, 12:33:02 PM5/17/19

to jenkinsc...@googlegroups.com

Liam Newman commented on

Audun Halland
The fact that build now is broken is extremely odd. Is it broken in the same way (same commits and message)? The place where "Build Now" calculates the HEAD of the base branch should be ignoring any filter.

bitwiseman@gmail.com (JIRA)

unread,

May 17, 2019, 2:14:02 PM5/17/19

to jenkinsc...@googlegroups.com

Liam Newman edited a comment on

[~audunhalland]

The fact that build now is broken is extremely odd. Is it broken in the same way (same commits and message)? The place where "Build Now" calculates the HEAD of the base branch should be ignoring any filter.

Update:
I've tested this with the Ignore Committer strategy and it works as expected: When I push a commit to master from a committer that should be ignored, the master branch doesn't build, but PR correctly detects the change and gets the most current commit from master which is the valid parent of the merge commit.

What other plugins do you have configured?

bitwiseman@gmail.com (JIRA)

unread,

May 17, 2019, 2:16:03 PM5/17/19

to jenkinsc...@googlegroups.com

Liam Newman edited a comment on

[~audunhalland]
The fact that build now is broken is extremely odd.  Is it broken in the same way (same commits and message)? The place where "Build Now" calculates the HEAD of the base branch should be ignoring any filter.

Update:
I've tested this with the Ignore Committer strategy and it works as expected: When I push a commit to master from a committer that should be ignored, the master branch doesn't build, but PR correctly detects the change and gets the most current commit from master which is the valid parent of the merge commit.

What other plugins do you have configured?

Also, out of curiosity are you using GitHub or GitHub Enterprise?

audun.halland@gmail.com (JIRA)

unread,

May 17, 2019, 3:59:03 PM5/17/19

to jenkinsc...@googlegroups.com

Audun Halland commented on

Regular github.com, our jenkins is set up to scan the github organization. The repo in question is a private repository.

According to the Organization configuration page, these settings are active:

Behaviours:

Discover branches, Strategy: Exclude branches that are also filed as PRs
Discover pull requests from origin, Strategy: Merging the pull request with the current target branch revision
Checkout over SSH, Credentials: ****

Project recognizers:

Pipeline Jenkinsfile, Script Path: Jenkinsfile

Build strategies:

Ignore committer strategy
- Don't trigger builds for pushes by certain Git commit author (comma-delimited list of author emails): [ci email address]
- Allow builds when a changeset contains non-ignored author(s): ENABLED

I might also add that when PR-47 was initially created, its branch was not up to date with master, and master got merged into it later, after its jenkins job was created. The latest commit of that PR currently is merge commit 5729, referencing child commits d75b (change set) + 76ff (master).

bitwiseman@gmail.com (JIRA)

unread,

May 18, 2019, 6:09:02 PM5/18/19

to jenkinsc...@googlegroups.com

Liam Newman commented on

Audun Halland
All that looks completely reasonable.

I've tried a creating a version that I think will unblock you.
Try installing this hpi: https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/github-branch-source/2.5.3-rc840.68a7449454be/

This version is much more accommodating - it will fall back to cloning locally on master if the merge_commit provided by github doesn't match up. Please give this a try and see how it works for you.

Please keep an eye on the scans and build logs and tell me what you see.

audun.halland@gmail.com (JIRA)

unread,

May 19, 2019, 5:33:03 PM5/19/19

to jenkinsc...@googlegroups.com

Audun Halland commented on

Thank you!

Scan log:

...
Checking pull request #47

{{ ‘Jenkinsfile’ found Invalid github merge_commit_sha for pull request 47 : Head and base commits do match merge commit 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (567c876ca2e53637b53edd7c4eedca77af15aa65), expected head and base 76ff9c62d27d6b60666c08d0686e3100974fd1fe+5729a1e31f5d0691d16801604312de0af03da009 Met criteria Changes detected: PR-47 (5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (567c876ca2e53637b53edd7c4eedca77af15aa65) → 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (UNKNOWN_MERGE_STATE)) Scheduled build for branch: PR-47 }}

Build log (it now starts building the pipeline):

Branch indexing
21:04:15 Connecting to https://api.github.com using c...@mydomain.com/******
Invalid github merge_commit_sha for pull request 47 : Head and base commits do match merge commit 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (567c876ca2e53637b53edd7c4eedca77af15aa65), expected head and base 76ff9c62d27d6b60666c08d0686e3100974fd1fe+5729a1e31f5d0691d16801604312de0af03da009
Checking out git g...@github.com:MyOrganization/my-repo.git into /var/jenkins_home/workspace/my-repo_PR-47@script to read Jenkinsfile
using credential github-sshkey
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository g...@github.com:MyOrganization/my-repo.git
{{ > git init /var/jenkins_home/workspace/my-repo_PR-47@script # timeout=10}}
Fetching upstream changes from g...@github.com:MyOrganization/my-repo.git
{{ > git --version # timeout=10}}
using GIT_SSH to set credentials MyJe...@github.com SSH key
{{ > git fetch --no-tags --force --progress g...@github.com:MyOrganization/my-repo.git +refs/pull/47/head:refs/remotes/origin/PR-47 +refs/heads/master:refs/remotes/origin/master}}
{{ > git config remote.origin.url g...@github.com:MyOrganization/my-repo.git # timeout=10}}
{{ > git config --add remote.origin.fetch +refs/pull/47/head:refs/remotes/origin/PR-47 # timeout=10}}
{{ > git config --add remote.origin.fetch +refs/heads/master:refs/remotes/origin/master # timeout=10}}
{{ > git config remote.origin.url g...@github.com:MyOrganization/my-repo.git # timeout=10}}
Fetching without tags
Fetching upstream changes from g...@github.com:MyOrganization/my-repo.git
using GIT_SSH to set credentials MyJe...@github.com SSH key
{{ > git fetch --no-tags --force --progress g...@github.com:MyOrganization/my-repo.git +refs/pull/47/head:refs/remotes/origin/PR-47 +refs/heads/master:refs/remotes/origin/master}}
Merging remotes/origin/master commit 7e881478aa951a0f9caad966907c68c5c058a935 into PR head commit 5729a1e31f5d0691d16801604312de0af03da009
{{ > git config core.sparsecheckout # timeout=10}}
{{ > git checkout -f 5729a1e31f5d0691d16801604312de0af03da009}}
{{ > git merge 7e881478aa951a0f9caad966907c68c5c058a935 # timeout=10}}
{{ > git rev-parse HEAD^{commit} # timeout=10}}
Merge succeeded, producing 5729a1e31f5d0691d16801604312de0af03da009
Checking out Revision 5729a1e31f5d0691d16801604312de0af03da009 (PR-47)
{{ > git config core.sparsecheckout # timeout=10}}
{{ > git checkout -f 5729a1e31f5d0691d16801604312de0af03da009}}
Commit message: "Merge branch 'master' of https://github.com/MyOrganization/my-repo into feature/search-api-new-branch"
First time build. Skipping changelog.
Running in Durability level: MAX_SURVIVABILITY
Loading library jenkins-pipeline-libraries@master
Examining MyOrganization/jenkins-pipeline-libraries
Attempting to resolve master as a branch
Resolved master as branch master at revision 190ac158caf5abb464702aa7515c417f01143052
using credential github-ci-username-password
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/MyOrganization/jenkins-pipeline-libraries.git
{{ > git init /var/jenkins_home/workspace/my-repo_PR-47@libs/jenkins-pipeline-libraries # timeout=10}}
Fetching upstream changes from https://github.com/MyOrganization/jenkins-pipeline-libraries.git
{{ > git --version # timeout=10}}
{{using GIT_ASKPASS to set credentials }}
{{ > git fetch --no-tags --force --progress https://github.com/MyOrganization/jenkins-pipeline-libraries.git +refs/heads/master:refs/remotes/origin/master}}
{{ > git config remote.origin.url https://github.com/MyOrganization/jenkins-pipeline-libraries.git # timeout=10}}
{{ > git config --add remote.origin.fetch +refs/heads/master:refs/remotes/origin/master # timeout=10}}
{{ > git config remote.origin.url https://github.com/MyOrganization/jenkins-pipeline-libraries.git # timeout=10}}
Fetching without tags
Fetching upstream changes from https://github.com/MyOrganization/jenkins-pipeline-libraries.git
{{using GIT_ASKPASS to set credentials }}
{{ > git fetch --no-tags --force --progress https://github.com/MyOrganization/jenkins-pipeline-libraries.git +refs/heads/master:refs/remotes/origin/master}}
Checking out Revision 190ac158caf5abb464702aa7515c417f01143052 (master)
{{ > git config core.sparsecheckout # timeout=10}}
{{ > git checkout -f 190ac158caf5abb464702aa7515c417f01143052}}
Commit message: "Fix typo"
First time build. Skipping changelog.
[Pipeline] Start of Pipeline
........ Lots of stuff .....

I figure it somehow still believes that 7e88 }}is master HEAD (based on {{Merging remotes/origin/master commit 7e881478aa951a0f9caad966907c68c5c058a935 into PR head commit 5729a1e31f5d0691d16801604312de0af03da009). It printed one correct reference to the true master HEAD (76ff) in the 3rd build log line.

audun.halland@gmail.com (JIRA)

unread,

May 19, 2019, 5:35:03 PM5/19/19

to jenkinsc...@googlegroups.com

Audun Halland edited a comment on

Thank you!

Scan log:

{{ {{ ...}} }}
{{ {{ Checking pull request #47}} }}

{{‘Jenkinsfile’ found Invalid github merge_commit_sha for pull request 47 : Head and base commits do match merge commit 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (567c876ca2e53637b53edd7c4eedca77af15aa65), expected head and base 76ff9c62d27d6b60666c08d0686e3100974fd1fe+5729a1e31f5d0691d16801604312de0af03da009 Met criteria Changes detected: PR-47 (5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (567c876ca2e53637b53edd7c4eedca77af15aa65) → 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (UNKNOWN_MERGE_STATE)) Scheduled build for branch: PR-47}}

Build log (it now starts building the pipeline):

{{Branch indexing}}

{{21:04:15 Connecting to [https://api.github.com|https://api.github.com/] using c...@mydomain.com/******}}

\ {{ > git rev-parse HEAD^

{commit}

I figure it somehow still believes that {{7e88 }}is master HEAD (based on {{Merging remotes/origin/master commit 7e881478aa951a0f9caad966907c68c5c058a935 into PR head commit 5729a1e31f5d0691d16801604312de0af03da009}}). It printed one correct reference to the true master HEAD ({{76ff}}) in the 3rd build log line.

audun.halland@gmail.com (JIRA)

unread,

May 19, 2019, 5:35:03 PM5/19/19

to jenkinsc...@googlegroups.com

Audun Halland edited a comment on

Thank you!

Scan log:

{{ {{ ...}} }}

{{ {{ Checking pull request [ #47 |https://github.com/universitetsforlaget/graphql-gateway/pull/47] }} }}

{{ ‘Jenkinsfile’ found Invalid github merge_commit_sha for pull request 47 : Head and base commits do match merge commit 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (567c876ca2e53637b53edd7c4eedca77af15aa65), expected head and base 76ff9c62d27d6b60666c08d0686e3100974fd1fe+5729a1e31f5d0691d16801604312de0af03da009 Met criteria Changes detected: PR-47 (5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (567c876ca2e53637b53edd7c4eedca77af15aa65) → 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (UNKNOWN_MERGE_STATE)) Scheduled build for branch: PR-47 }}

[ https://api.github.com |https://api.github.com/] using c...@mydomain.com/******}}

audun.halland@gmail.com (JIRA)

unread,

May 19, 2019, 5:37:03 PM5/19/19

to jenkinsc...@googlegroups.com

Audun Halland edited a comment on

Thank you!

Scan log:

{{...}}
{{Checking pull request #47}}

{{‘Jenkinsfile’ found Invalid github merge_commit_sha for pull request 47 : Head and base commits do match merge commit 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (567c876ca2e53637b53edd7c4eedca77af15aa65), expected head and base 76ff9c62d27d6b60666c08d0686e3100974fd1fe+5729a1e31f5d0691d16801604312de0af03da009 Met criteria Changes detected: PR-47 (5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (567c876ca2e53637b53edd7c4eedca77af15aa65) → 5729a1e31f5d0691d16801604312de0af03da009+7e881478aa951a0f9caad966907c68c5c058a935 (UNKNOWN_MERGE_STATE)) Scheduled build for branch: PR-47}}

audun.halland@gmail.com (JIRA)

unread,

May 19, 2019, 5:38:02 PM5/19/19

to jenkinsc...@googlegroups.com

audun.halland@gmail.com (JIRA)

unread,

May 19, 2019, 5:40:03 PM5/19/19

to jenkinsc...@googlegroups.com

timeout=10}}

{{ > git config --add remote.origin.fetch +refs/heads/master:refs/remotes/origin/master timeout=10}}

{{ > git config remote.origin.url [https://github.com/MyOrganization/jenkins-pipeline-libraries.git] # timeout=10}}
{{Fetching without tags}}
{{Fetching upstream changes from [https://github.com/MyOrganization/jenkins-pipeline-libraries.git]}}
{{using GIT_ASKPASS to set credentials }}
{{ > git fetch --no-tags --force --progress [https://github.com/MyOrganization/jenkins-pipeline-libraries.git] +refs/heads/master:refs/remotes/origin/master}}
{{Checking out Revision 190ac158caf5abb464702aa7515c417f01143052 (master)}}
{{ > git config core.sparsecheckout # timeout=10}}
{{ > git checkout -f 190ac158caf5abb464702aa7515c417f01143052}}
{{Commit message: "Fix typo"}}
{{First time build. Skipping changelog.}}
{{[Pipeline] Start of Pipeline}}
{{........ Lots of stuff .....}}

I figure it somehow still believes that {{7e88}} is master HEAD (based on {{Merging remotes/origin/master commit 7e881478aa951a0f9caad966907c68c5c058a935 into PR head commit 5729a1e31f5d0691d16801604312de0af03da009}}). It printed one correct reference to the true master HEAD ({{76ff}}) in the 3rd build log line.

audun.halland@gmail.com (JIRA)

unread,

May 19, 2019, 5:42:01 PM5/19/19

to jenkinsc...@googlegroups.com

Audun Halland commented on

Sorry, I had some formatting problems pasting the logs into the previous comment.

bitwiseman@gmail.com (JIRA)

unread,

May 20, 2019, 10:09:02 PM5/20/19

to jenkinsc...@googlegroups.com

Liam Newman commented on