Cannot set `GitSCMStatusChecksExtension` when `GitSCMChecksContext` uses `BuildData` about github-checks-plugin

[KalleOlaviNiemitalo]

There is also BuildStatusChecksPublisher.JobScheduledListener.onEnterWaiting, which calls getChecksName with a Job rather than a Run: https://github.com/jenkinsci/checks-api-plugin/blob/4996cf43478acbd1a3043225af2b9d7849c6c174/src/main/java/io/jenkins/plugins/checks/status/BuildStatusChecksPublisher.java#L127-L129

I don't think that will ever be able to get the checks name defined in a pipeline script… but then again, it does not know the SCM settings defined in the pipeline either, so it won't be posting checks with an incorrect name to that SCM.

[agaudreault]

You are right. onEnterWaiting does not matter much in this scenario because the SCM is not present on the job so it won't publish anything. However, after the first checkout step, it will start to publish in onCheckout and onCompleted because checkout will add BuildData. But from there, we have access to the run object, so we could, if present, use information in the Run when scm is not defined.

[KalleOlaviNiemitalo]

What should happen if the pipeline runs multiple checkout steps, with a GitSCMStatusChecksExtension in each? Should it publish IN_PROGRESS to each repository after the corresponding checkout, and then COMPLETED to every repository when the run completes?

[agaudreault]

I think these can be 2 different problems. If the GitSCMChecksContext uses the first build data only, then it should respect the associated GitSCMStatusChecksExtension configuration of this build data. If it has a mechanism to loop through all buildData (from different checkout steps), then it should respect their own configuration and publish the completed check for all of them.

I think the first step would be to be able to get the GitSCMStatusChecksExtension for a specific build data first.

When that is working, sending a check for multiple checkout step could be added. I can easily imagine a use case where there are 2 checkouts, but only the second one is in the right repo and should have the check. The user would need to specify in the first checkout to skip the check.