Cannot set `GitSCMStatusChecksExtension` when `GitSCMChecksContext` uses `BuildData`

[agaudreault]

Description

Default checks are published to GitHub with the name Jenkins when no SCM is configured on the job (CpsFlowDefinition). A valid GitSCMChecksContext is created because the build contains a valid hudson.plugins.git.util.BuildData object.

That is awesome, however, it is not currently possible to skip that check or to configure the name.

Steps to reproduce

1. Create a new pipeline job
2. Use the following pipeline script
3. Run the job

#!/usr/bin/groovy

node {
    stage ('checkout') {
        checkout scm: [
            $class: 'GitSCM',
            branches: [[name: "*/master"]],
            extensions: [
                [$class: 'CleanBeforeCheckout'],
                [$class: 'GitSCMStatusChecksExtension', name: 'Custom Name', skip: false]
            ],
            userRemoteConfigs: [[credentialsId: 'your-github-app-credential', url: 'https://github.com/user/repo.git']]
        ]
    }
}

Current behaviour

[...]
Fetching changes from the remote Git repository
[...]
[GitHub Checks] GitHub check (name: Jenkins, status: IN_PROGRESS) has been published.

Expected behaviour

[...]
Fetching changes from the remote Git repository
[...]
[GitHub Checks] GitHub check (name: Custom Name, status: IN_PROGRESS) has been published.

Implementation suggestion

I am not sure I know where to start with this issue. The configuration are retrieved in BuildStatusChecksPublisher. They could try to retrieve some config persisted in the Run object (like BuildData) to know the check property. At the moment, GitSCMStatusChecksExtension is not persisted in the Run.

[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-jive]

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-jive]

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.