jenkinsci
[JENKINS-40150] Git operations fail after global lib is loaded
We have a single global library defined loaded from github. When we're running longer-running builds, we set the status of the commit using the GitHubCommitStatusSetter step:
step([$class: 'GitHubCommitStatusSetter', statusResultSource: [$class: 'ConditionalStatusResultSource', results: []]])
Say the library is called LIB and the project we're building (also on github) is APP, when the above step is executed it tries to set the commit status with the commit-hash from APP on the repository LIB, which then fails because the LIB doesn't have this commit hash.
org.jenkinsci.plugins.github.common.CombineErrorHandler$ErrorHandlingException: java.io.FileNotFoundException: {"message":"No commit found for SHA: 172fd52d6393fae44ee1d962dc26098846489e1e","documentation_url":"https://developer.github.com/v3/repos/statuses/"}
I think I can around this by explicitly specifying the repository in the GitHubCommitStatusSetter but ideally that shouldn't be necessary.
Originally reported by 
gijsk, imported from: Git operations fail after global lib is loaded
- assignee:
lanwen
- status: Open
- priority: Minor
- component(s): github-plugin
- label(s): github, pipeline
- resolution: Unresolved
- votes: 2
- watchers: 8
- imported: 2025-12-08
Raw content of original issue
We have a single global library defined loaded from github. When we're running longer-running builds, we set the status of the commit using the GitHubCommitStatusSetter step:
step([$class: 'GitHubCommitStatusSetter', statusResultSource: [$class: 'ConditionalStatusResultSource', results: []]])Say the library is called LIB and the project we're building (also on github) is APP, when the above step is executed it tries to set the commit status with the commit-hash from APP on the repository LIB, which then fails because the LIB doesn't have this commit hash.
org.jenkinsci.plugins.github.common.CombineErrorHandler$ErrorHandlingException: java.io.FileNotFoundException: {"message":"No commit found for SHA: 172fd52d6393fae44ee1d962dc26098846489e1e","documentation_url":"https://developer.github.com/v3/repos/statuses/"}I think I can around this by explicitly specifying the repository in the GitHubCommitStatusSetter but ideally that shouldn't be necessary.
- environment:
Jenkins 2.21
integer:
- Original comment link
Raw content of original comment:
Workflow, cps or whatever it is probably should set context of executed code to job. I see nothing that github-plugin could do for workflow magic. If somebody will know solution, issue could get github-plugin component back.
Workflow, cps or whatever it is probably should set context of executed code to job. I see nothing that github-plugin could do for workflow magic. If somebody will know solution, issue could get github-plugin component back.
jglick:
- Original comment link
Raw content of original comment:
Use status notifications from github-branch-source, which will track SCMRevisionAction, or make GitHubCommitStatusSetter do the same.
Use status notifications from github-branch-source, which will track SCMRevisionAction, or make GitHubCommitStatusSetter do the same.
lanwen:
- Original comment link
Raw content of original comment:
Can you add more detailed example?
I'm not very familiar with pipeline ecosystem, so it will be very helpful if i can reproduce exact your usecase.
Can you add more detailed example?
I'm not very familiar with pipeline ecosystem, so it will be very helpful if i can reproduce exact your usecase.
lalmeras:
- Original comment link
Raw content of original comment:
Hi,
I encounter a related but different issue. If I use an external pipeline library (via Jenkinsfile), github notifications are pushed with pipeline library's SHA instead of project SHA. I succeed to workaround it with a quick and dirty fix : https://github.com/lalmeras/github-plugin/commit/2f038d249bc142163b2866cf863ebb27ee49c629 As jglick suggests, it use SCMRevisionAction in place of BuildData.
I think github plugin should provide at least a GitHubCommitShaSource implementation that handles SCMRevisionAction. It also seems to me that SCMRevisionAction may be a better default as other plugins switch to it for the same reason : https://issues.jenkins-ci.org/browse/JENKINS-42809
About gijsk's problem I think it is not related to pipeline's library, so he may need to handle manually SHA with this help https://wiki.jenkins-ci.org/display/JENKINS/Github+Plugin#GitHubPlugin-Settingcommitstatus
Hi,
I encounter a related but different issue. If I use an external pipeline library (via Jenkinsfile), github notifications are pushed with pipeline library's SHA instead of project SHA.
I succeed to workaround it with a quick and dirty fix : https://github.com/lalmeras/github-plugin/commit/2f038d249bc142163b2866cf863ebb27ee49c629
As jglick suggests, it use SCMRevisionAction in place of BuildData.
I think github plugin should provide at least a GitHubCommitShaSource implementation that handles SCMRevisionAction. It also seems to me that SCMRevisionAction may be a better default as other plugins switch to it for the same reason : https://issues.jenkins-ci.org/browse/JENKINS-42809
About gijsk's problem I think it is not related to pipeline's library, so he may need to handle manually SHA with this help https://wiki.jenkins-ci.org/display/JENKINS/Github+Plugin#GitHubPlugin-Settingcommitstatus
lalmeras:
- Original comment link
Raw content of original comment:
I post on https://issues.jenkins-ci.org/browse/JENKINS-42809 as it seems to me that BuildData's behavior change (it now exposes pipeline's lib information instead of project information) may need to be reworked or explain before we can fix this issue.
If anyone could confirm or refute my analysis ?
I post on https://issues.jenkins-ci.org/browse/JENKINS-42809 as it seems to me that BuildData's behavior change (it now exposes pipeline's lib information instead of project information) may need to be reworked or explain before we can fix this issue.
If anyone could confirm or refute my analysis ?
jglick:
- Original comment link
Raw content of original comment:
BuildData's behavior change (it now exposes pipeline's lib information instead of project information)
No, it exposes both. In general there could be any number of BuildData attached to a given build. It is up to the caller to select which BuildData it cares about; or use SCMRevisionAction if it is specifically looking for the multibranch commit.
BuildData's behavior change (it now exposes pipeline's lib information instead of project information)
No, it exposes both. In general there could be any number of BuildData attached to a given build. It is up to the caller to select which BuildData it cares about; or use SCMRevisionAction if it is specifically looking for the multibranch commit.
lalmeras:
- Original comment link
Raw content of original comment:
Thanks for your insight on BuildData. I'll try to figure out the best way to handle my case (lookup SHA from project repo to set commit status when a pipeline's lib is used).
Thanks for your insight on BuildData. I'll try to figure out the best way to handle my case (lookup SHA from project repo to set commit status when a pipeline's lib is used).