Ability to add buttons in the publishChecks pipeline step about checks-api-plugin

[KalleOlaviNiemitalo]

There are a few possible improvements:

• Add public void applyTo(ChecksDetails) to ChecksInfo and make consumers call that instead of copying the name themselves. This would let later versions of checks-api-plugin add features to ChecksInfo without always needing more changes in consumers.
• Give StepContext or just StepContext::get as a parameter to ChecksPublisherFactory.createPublisher. This would let implementing plugins define pipeline steps that add SCM-specific info types to the context, and then look them up when publishing. This would belong in ChecksPublisherFactory rather than ChecksPublisher, so that the SCM-specific info could include API endpoints etc. and make the ChecksPublisherFactory eligible even if it would not otherwise be.

I should file separate requests for those, I guess.

[XiongKezhi]

do you mean the actions in GitHub checks API? And when you click on that button, a request from GitHub will be sent to your Jenkins? May I ask what are you going to use it for?

[tallen1983]

@XiongKezhi yes, I actually meant to put this on jenkinsci/github-checks-plugin (I had both tabs open). Oops.

There could be any number of reasons to add actions. Perhaps someone builds debug by default as a PR check, but sometimes they want a release build (or vice versa). Maybe it annotated a couple lines which can be auto-fixed with a "Fix these" action, etc.

[XiongKezhi]

I'm planning to implement this, along with #28.

But the only thing we can do is no more than exposing the API to add action buttons, the handlers/subscribers for those actions still need the implementation from the users themselves, like https://github.com/jenkinsci/github-checks-plugin/blob/master/src/main/java/io/jenkins/plugins/checks/github/CheckRunGHEventSubscriber.java.

[KalleOlaviNiemitalo]

A use case that may be relevant:

I have a Jenkins job that builds HTML documentation and publishes it to a web server (as opposed to having Jenkins serve it). I'd like to post the web server address to the SCM system as part of a checks report, so that I can browse to it without going through Jenkins. However, the SCM is not GitHub and does not support Markdown in the report. Instead, it supports links that have a title and a URL. If I could have the Jenkinsfile generate the web site URL and publish that via Checks API as if it were an action, then that would be cool. Thus, I hope that the actions API being added will allow URLs that do not point to Jenkins.

It would be even better if I could make the link part of the checks report that is already published by another plugin, rather than a separate report. I imagine the withChecks step could be changed to take links as an argument. With the current Checks API though, it seems this would require changing the consumer plugins such as Warnings NG as well, because implementations of ChecksPublisher cannot discover ChecksInfo themselves.

[XiongKezhi]

... Instead, it supports links that have a title and a URL ... Thus, I hope that the actions API being added will allow URLs that do not point to Jenkins.

If only considering GitHub, this is not possible. The action for GitHub is just adding buttons to the checks report and used for users to require additional behavior that is pre-defined in Jenkins. But since we are now at the API level and as you said, the SCM is not GitHub, so we can discuss and define a wider-scoped API (not only in this action part) for users if we can have a better abstraction beyond the GitHub one.

I imagine the withChecks step could be changed to take links as an argument. With the current Checks API though, it seems this would require changing the consumer plugins such as Warnings NG as well, because implementations of ChecksPublisher cannot discover ChecksInfo themselves.

This could be done, and yes, this requires changes of the consumers. But if we want to forcefully change the link published by consumers, maybe we need another step, since it's not our purpose of the withChecks.

[XiongKezhi]

The basic functionality to add action buttons is fixed by #85.