[JENKINS-46795] TrustworthyBuild extension point#180
[JENKINS-46795] TrustworthyBuild extension point#180jglick wants to merge 10 commits intojenkinsci:masterfrom
TrustworthyBuild extension point#180Conversation
| return TrustworthyBuild.byCause(Cause.UserIdCause.class); | ||
| } | ||
|
|
||
| // TODO until github-checks can declare a dep on a sufficiently new scm-api |
There was a problem hiding this comment.
| } | ||
| try { | ||
| var permission = Run.PERMISSIONS.find("Replay"); // ReplayAction.REPLAY | ||
| if (permission == null) { // no workflow-cps |
There was a problem hiding this comment.
Could be defined more modularly as an extension in workflow-cps, but would be awkward since the rest of this impl would need to be duplicated, and ordinal used to avoid printing misleading messages.
In practice the callers of getTrustedRevisionForBuild are going to be in Pipeline code so I am not too concerned.
| listener.getLogger().println("Not trusting build since no user name was recorded"); | ||
| return false; | ||
| } | ||
| var user = User.getById(userId, false); |
There was a problem hiding this comment.
Could pass true but we expect the User to have just been loaded anyway.
| @Extension | ||
| public static TrustworthyBuild byUserId() { | ||
| return (build, listener) -> { | ||
| var cause = build.getCause(Cause.UserIdCause.class); |
There was a problem hiding this comment.
While it should be rare, there can be multiple causes of the same type for a build that aren't collapsed into one entry. Whether a build is approved or not could depend on the (insertion) order of the CauseAction#causeBag.
There was a problem hiding this comment.
there can be multiple causes of the same type for a build that aren't collapsed into one entry
The API does not prevent it but this ought never happen—it is the responsible of code triggering the build to pass at most one Cause of any given type. At worst a build is not considered trusted when it could have been, so this does not seem like a problem in practice.
…into trust-JENKINS-46795
…uild (e.g., SCM trigger) where this does not matter (e.g., branch push) jenkinsci#180 (comment)
daniel-beck
left a comment
daniel-beck
left a comment
There was a problem hiding this comment.
The behavior introduced here makes sense.
I am not too familiar with the design of SCM API so cannot really comment on whether the code is placed appropriately, but see nothing particularly wrong either.
|
Putting API on hold since there is active design conversation downstream. |
Where? It seems over in jenkinsci/workflow-multibranch-plugin#220 (comment) |
4 participants
jenkinsci/workflow-multibranch-plugin#220 (comment)