-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
CloudBees Jenkins Enterprise 2.107.34.0.1-fixed
GitHub API Plugin 1.90
GitHub Branch Source Plugin 2.3.5
GitHub can incorrectly flag PRs as passing checks if multiple jobs run against the same repository.
Multiple jobs configured against the same source repo will incorrectly set all checks successful if the last completed check is successful.
In my opinion, if there is no mechanism to define mandatory and optional checks, then the worst status check should provide the overall result.
This could be a check prior to submitting status that validates the prior status is not unsuccessful, and it is the same git sha1, and it is a different job name.
The secondary issue here is that only a single link is added to the PR, and so there is no indication on the GitHub PR how many jobs ran.
- is related to
-
JENKINS-46119 Use the job name in context string
-
- Resolved
-
-
JENKINS-56853 Pull Request validation by multiple jenkins - webhook name configuration
-
- Open
-
- relates to
-
JENKINS-62924 pr-merge status notification sent to GitHub applies to multiple PRs if source branch has multiple PRs opened to different target branches
-
- Open
-
[JENKINS-55726] GitHub commit status context not unique enough or configurable - jobs always overwrite each other
Link | New: This issue is related to JENKINS-56853 [ JENKINS-56853 ] |
Link |
New:
This issue is related to |
Description |
Original:
Multiple jobs configured against the same source repo will incorrectly set all checks successful if the last completed check is successful. In my opinion, if there is no mechanism to define mandatory and optional checks, then the worst status check should provide the overall result. This could be a check prior to submitting status that validates the prior status is not unsuccessful, and it is the same git sha1, and it is a different job name. The secondary issue here is that only a single link is added to the PR, and so there is no indication on the GitHub PR how many jobs ran. |
New:
GitHub can incorrectly flag PRs as passing checks if multiple jobs run against the same repository. Multiple jobs configured against the same source repo will incorrectly set all checks successful if the last completed check is successful. In my opinion, if there is no mechanism to define mandatory and optional checks, then the worst status check should provide the overall result. This could be a check prior to submitting status that validates the prior status is not unsuccessful, and it is the same git sha1, and it is a different job name. The secondary issue here is that only a single link is added to the PR, and so there is no indication on the GitHub PR how many jobs ran. |
Summary | Original: GitHub can incorrectly flag PRs as passing checks if multiple jobs run against the same repository | New: GitHub commit status context not unique enough or configurable - jobs always overwrite each other |
Related to
JENKINS-37100andJENKINS-36574- I think the latter may be the genesis for the current situation, which may have been a fix by jglick?I read through those bugs and can definitely see why the code is as it currently is, but I think an improvement can be made to satisfy both the current use case and also improve the situation where multiple Jenkins jobs are reporting to the single repository.
I saw this mentioned but no discussion as to why it was ultimately not followed, so if there are issues then please do explain.
The prime requirements for blocking merges is that there is a single string that any PR presents to GitHub so the repository settings can indicate the status of that context must be success prior to merge.
This is currently set to "continuous-integration/jenkins/pr-merge".
The issue is that every Jenkins job returns that same context.
In the case of a Multibranch configuration using GitHub, we will have a job whose name is [<folder>/]*<job>/<branch> where <branch> is either a branch or a special branch representing a Pull Request.
The branch string changes each time a new branch or pull request is created, and this makes it unsuitable to be used as a merge gate for GitHub. I would state that the enclosing job name is perfectly viable to use as a status context though, as that is unchanging across multiple Pull Requests.
So the above code would become something like: