Details
-
Bug
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
None
-
CloudBees Jenkins Enterprise 2.107.34.0.1-fixed
GitHub API Plugin 1.90
GitHub Branch Source Plugin 2.3.5
Description
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.
Attachments
Issue Links
- 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
-
-
- Open
-
Activity
nozomu_honda - as you changed the status to in progress, could you answer bitwiseman’s question please?
Sorry for my late reply.
I changed the status unintentionally.
Please change it back to open.
https://github.com/jenkinsci/github-scm-trait-notification-context-plugin works like a charm for me with multi branch pipelines. It is also configurable via job-dsl:
// Defines a custom context label to be sent as part of Github Status notifications for this project.
notificationContextTrait {
// The text of the context label for Github status notifications.
contextLabel(String value)
// Appends the relevant suffix to the context label based on the build type.
typeSuffix(boolean value)
}
Pascal Hofmann
added a comment - - edited https://github.com/jenkinsci/github-scm-trait-notification-context-plugin works like a charm for me with multi branch pipelines. It is also configurable via job-dsl:
// Defines a custom context label to be sent as part of Github Status notifications for this project.
notificationContextTrait {
// The text of the context label for Github status notifications.
contextLabel (String value)
// Appends the relevant suffix to the context label based on the build type.
typeSuffix (boolean value)
} bitwiseman, I finished rejoicing, but I'm not sure I'm ready to close this yet.
I guess my main concern is that the default behaviour of Jenkins is one that allows loss of data and incorrect code merges.
I would like to see can the default string be a safe alternative based on the job name in some way, rather than relying on either only a single job per repository, or the user knowing of the weakness and knowing to get the extra plugin to configure each of their jobs appropriately.
j3p0uk
What I meant was that JIRA says you changed this issue to "In Progress" and I wanted to know if you were working on it. If not, I'll change it back to open.