jenkinsci / checks-api-plugin

Jenkins plugin that defines an API for Jenkins to publish checks to SCM platforms.

Checks API Plugin

Inspired by the GitHub Checks API, this plugin aims to provide a general API to allow Jenkins plugins publishing checks (or reports) to remote source code management (SCM) platforms (e.g. GitHub, GitLab, BitBucket, etc.).

By consuming this API, other plugins can publish check with customized parameters for a Jenkins build, such as status, summary, warnings, code annotations, or even images. Implementations of this API decide on how to make use of these parameters and where to publish the checks.

Known consumers:

• Warnings Next Generation Plugin
• Code Coverage API Plugin
• JUnit Plugin - since 1.39
• xUnit Plugin - since 3.1.0
• Autograding Plugin

Implementations:

• GitHub Checks Plugin
• Gitea Checks Plugin

This plugin, along with its GitHub implementation, has been installed on ci.jenkins.io to help maintain over 1500 Jenkins plugins. You can take a look at the action for this repository or other plugin repositories under Jenkins organization for the results.

Embedded Features

Build Status Check

This plugin defines extension points to publish statuses to different SCM platforms.

It depends on the implementation to decide whether to skip them and what name to use.

If enabled, the statuses will be published in different stages of a Jenkins build (enters the queue, checkout, and completes).

Pipeline Usage

• publishChecks: you can publish checks directly in the pipeline script instead of depending on consumer plugins:

publishChecks name: 'example', title: 'Pipeline Check', summary: 'check through pipeline',
    text: 'you can publish checks in pipeline script',
    detailsURL: 'https://github.com/jenkinsci/checks-api-plugin#pipeline-usage',
    actions: [[label:'an-user-request-action', description:'actions allow users to request pre-defined behaviours', identifier:'an unique identifier']]

To use customized actions, you will need to write a Jenkins plugin. If you want to add GitHub checks actions, which are basically buttons on the checks report, you need to extend GHEventSubscriber to handle the event, see the handler for re-run requests as an example.

• withChecks: you can inject the check's name into the closure for other steps to use:

withChecks('injected name') {
    // some other steps that will extract the name
}

withChecks will publish an in progress check immediately and then other consuming plugins will publish the final check.

You can also include the checks stage name with includeStage:

withChecks(name: 'Tests', includeStage: true) {
    sh 'mvn -Dmaven.test.failure.ignore=true clean verify'
    junit '**/target/surefire-reports/TEST-*.xml'
}

Combining includeStage with the JUnit plugin works well to publish checks for each test suite:

Example full pipeline with parallel stages

def axes = [
        platforms: ['linux', 'windows'],
        jdks: [17, 21],
]
def builds = [:]
axes.values().combinations {
    def (platform, jdk) = it
    builds["${platform}-jdk${jdk}"] = {
        node(platform) {
            stage("${platform.capitalize()} - JDK ${jdk} - Test") {
                checkout scm
                withChecks(name: 'Tests', includeStage: true) {
                    sh 'mvn -Dmaven.test.failure.ignore=true clean verify'
                    junit '**/target/surefire-reports/TEST-*.xml'
                }
            }
        }
    }
}

parallel builds

Guides

• Consumers Guide
• Implementation Guide

Contributing

Refer to our contribution guidelines

Acknowledgements

This plugin was started as a Google Summer of Code 2020 project, special thanks to the support from Jenkins GSoC SIG and the entire community.

LICENSE

Licensed under MIT, see LICENSE

checks-api-plugin's Issues

Unstable builds are treated as neutral

Unstable builds contains test failures and should be marked as failed

See

checks-api-plugin/src/main/java/io/jenkins/plugins/checks/BuildStatusChecksPublisher.java

Line 94 in 3d21dbb

return ChecksConclusion.NEUTRAL;

https://gitter.im/jenkinsci/warnings-plugin?at=5f32ff4d4c89605c7f8d6b27

cc @XiongKezhi

Dependencies of flattened POM of latest release do not match `MANIFEST.MF`

#229 pulled in jenkinsci/analysis-pom-plugin#737 which pulled in jenkinsci/plugin-pom#724 which pulled in mojohaus/flatten-maven-plugin#329 which broke the flattened POM: it no longer declares the plugin-to-plugin dependencies on commons-text-api and commons-lang3-api as explained in jenkinsci/bom#2484 (comment).

Add publisher for test.

Currently, we don't have a reliable way to test the features (e.g. status checks, checks steps) that require the involvement of an implementation. Thus, adding a LogPublisher only for testing that logs the check details or anything being published is a good way to improve our test coverage and quality.

After injecting the LogPublisher into the Jenkins instance while testing, we can later check the log to make assertions, examples are like:

checks-api-plugin/src/test/java/io/jenkins/plugins/checks/steps/PublishChecksStepITest.java

Line 28 in 75b92fb

assertThat(JenkinsRule.getLog(buildSuccessfully(job)))

Build log Output truncated. - print tail of log instead of head

Dependencies

Feature Request

Our pipeline step prints a decent amount to the console logs:

wc ci_output/make.out
 3186  25671 294530 ci_output/make.out

When it fails, the majority of useful prints are at the end.

As an alternative, would it be possible to get publish the tail of the Build log?

Ideally I'd like to see the full Build log, but I don't know the reason(s) why it is currently getting truncated or what the limit is (Jenkins vs GitHub restrictions/limitations?)

Ability to reuse/update checks

Coming from jenkinsci/junit-plugin#210...

We're making extensive use of the checks API now, and so far it's absolutely fantastic. The final missing piece of the jigsaw is the ability to update and reuse checks.

We have moved from reusing statuses, where we would ping a 'queued', 'in progress', and 'success'/'failure' message as appropriate, as tests progressed.

With checks, we are unable to do this (properly) via the provided API, and so results only get reported when a task is complete. We could publish a new check with the same name, but then we lose things like duration.

My ideal API would look something like:

withCheck('My Check Name') { check ->
    def result = sh script: 'build', returnStdout: true
    check.success(message: result)
}

and, for use with another plugin

withCheck('My Check Name') { check ->
    sh 'test --output output.xml'
    junit testResults: 'output.xml', check: check
}

where the implementation of withCheck is (in psuedo code) something like

void withCheck(String name, Closure body) {
    def check = createCheck(name)
    try {
        body(check)
    catch (FlowInterruptedException f)  {
        check.abort()
        throw f
    }
    catch (Exception err) {
        check.fail()
        throw err
    }
    if (!check.complete) {  // ie, only call success if nothing else has already 'closed' the check
        check.success()
    }
}

Steps with labels are not logged as errors

Jenkins and plugins versions report

Environment

Jenkins: 2.440.1
OS: Linux - 5.10.198-187.748.amzn2.x86_64
Java: 17.0.10 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)
---
...
checks-api:2.0.2
...

What Operating System are you using (both controller, and any agents involved in the problem)?

Docker image for the controller and linux and macos agents

Reproduction steps

1. Setup a github multibranch project and github checks
2. Add a Jenkinsfile with

   sh(label: "Test", script: "false")
   

3. Create a PR for Jenkins to build

Expected Results

The Jenkins checks result should show that the sh step had an error in the summary and also indicate an error in the details (text)

Actual Results

No error is shown in the summary and the details lists the step without an error.

Anything else?

I think the problem is in

checks-api-plugin/src/main/java/io/jenkins/plugins/checks/status/FlowExecutionAnalyzer.java

Lines 167 to 168 in 09a2925

	final Pair<String, String> nodeInfo = stageOrBranchName.map(s -> processStageOrBranchRow(row, s))
	.orElseGet(() -> processErrorOrWarningRow(row, errorAction, warningAction));

It should probably prioritize the error check even if it has a name.

Are you interested in contributing a fix?

I'd be willing to make a PR, but I'm not sure about the original intentions of the code.

Primary error message is not shown in error header, instead says `error in 'error' step`

Feature Request

When I report an error like this in one of my steps:

stage ("Submodule Check") {
  steps {
    script {
      error "Submodules are OK for branches but cannot be merged into main"
    }
  }
}

This plugin does not report that error cleanly in the check. I expect it to show the message I reported more prominently but instead it shows information about the error step itself.

For example right in the Pull Request instead of showing that error message it simply says error in 'error' step:

Other github status checkers will show the actual error message in this part of the UI instead.

Additionaly when going to the error details it has the same message prominently in a header as well as some redundant information about an Error in the error step.

(red for bad, green for good)

I feel like in the case of reporting an error via the error() step / function, the information about that step should be omitted and the error message itself should be what is reported.

How to publish checks from sub-jobs

Describe your use-case which is not covered by existing documentation.

I am trying to figure out how it might be possible to publish checks from within a sub-job.

We have many microservices which all are built on top of a common framework. We would like to have one shared job that contains all of the logic related to performing CI for all of these microservices. That way, the Jenkinsfile in each microservice can be kept simple (it just runs the shared CI job) and doesn't need to be changed across dozens of places every time we want to add/modify how their CI works. We'd like to publish custom checks from within the shared sub-job, since that's where we'll have things like junit results/etc.

Do you have any information or examples for how we might be able to pass through the context necessary to publish a check from a sub-job? I haven't had luck finding relevant information through my searches thus far.

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

[doc] How to get started?

Describe your use-case which is not covered by existing documentation.

Hello, bear with me with my limited understanding of this plugin and maybe Jenkins plugin overall, but I am not sure how to get started after installing this plugin on my Jenkins.
The consumer guide asks me to write some codes. Where/why do I have to code to make this plugin work? Do you have a Youtube video to instruct how to get started? Thanks in advance.

Also, have a question about the use case.
My use case is I have a project, not a pipeline, that is built on Jenkins behind a firewall. Whenever there's a Jenkins build, I want to associate the build with a Github pull request by requesting people manually input it and once the build finishes up, Jenkins can post the build status as Status Check on this PR to either approve or block the merge button. Can I use this plugin for my purpose?

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

Cannot build plugin

Since the addition of the withChecks (#49), I've been unable to build locally, due to the error:

 Failed to resolve new artifacts: Could not find artifact io.jenkins.plugins:checks-api:hpi:1.2.0null in repo.jenkins-ci.org (https://repo.jenkins-ci.org/public/). The API analysis will not proceed.

Adding back the -SNAPSHOT to the pom doesn't help, as it then complains about breaking semantic versioning.

Out of interest, I tried bumping to 2.0.0 (with -SNAPSHOT), which succeeded, but with:

Failed to resolve old artifacts: Could not find artifact io.jenkins.plugins:checks-api:hpi:1.2.0${changelist} in repo.jenkins-ci.org (https://repo.jenkins-ci.org/public/). The API analysis will proceed comparing the new archives against an empty archive.

:(

Return information about the check

What feature do you want to see added?

When calling publishChecks it would be nice to get some information about the checks such as the ID, URL, etc

We have a usecase where we want to add a link to the checks run in a github comment, and currently this isn't possible without the check run id.

Upstream changes

No response

Are you interested in contributing this feature?

No response

A build result of UNSTABLE should not necessarily result in a failure

This line here:

checks-api-plugin/src/main/java/io/jenkins/plugins/checks/status/BuildStatusChecksPublisher.java

Line 146 in fa7f8da

else if (result.isBetterOrEqualTo(Result.UNSTABLE) || result.isBetterOrEqualTo(Result.FAILURE)) {

I wish it would return state NEUTRAL or success, or perhaps be configurable.

I have a step which is currently producing errors which I want to know about but cannot block the build for. For example linter errors. We introduced a linter and it generates warnings which we want to fix over time and then eventually flip to a hard FAILURE but for now I want it to show as UNSTABLE.

I would create a PR if I had some guidance how best to implement such a change.

publishChecks step: the conclusion should be none when status is not completed

Currently, the publishChecks step has a default success value for the conclusion, however, it should reset the conclusion to be none when the status is queued or in_progress. Otherwise, users may have to explicitly set the conclusion to be none since, like GitHub, it will automatically set the status to be completed when conclusion is provided.

See the context: #70 (comment)

Possibility Of Specifying Credentials

Describe your use-case which is not covered by existing documentation.

Hi there,

I was wondering if there is the possibility of specifying the credentials for junit when it publishes to GitHub Checks?

Since the project is maybe not "org" based but knowing that - using my setup GitHub App Credential:

               withCredentials([usernamePassword(credentialsId: 'jenkins-irishgordo',
                                            usernameVariable: 'GITHUB_APP',
                                            passwordVariable: 'GITHUB_ACCESS_TOKEN')]) { 
               }

In the withCredentials block on the pipeline -> stages -> stage -> steps.
I know that I'm capable of making a raw curl -X POST to https://api.github.com/repos/-usr-/repo/check-runs

Is there anyway to inject credentials into:

                withChecks('API Tests'){
                    junit checksName: 'api-tests', testResults: 'tests/api_latest.xml'
                }

I guess the use-case is right now - that a Jenkinsfile - builds a JobDSL based "pipelineJob" - that then that injects a basic declaritive pipeline script .groovy.
The triggers are setup on the JobDSL based Groovy file, with githubPullRequest -> since this is all outside of an Organization folder - I'm just wondering if selecting the credential to use could be a stand-in segway.

Thanks for any info / help / insight!
I really appreciate it all!
I also really appreciate that there is the ability to pulbish your junit results out to GitHub Checks, I think it's fantastic not having to head over to Jenkins to see the failures of the tests but instead have the tests runs propegeate to the Checks tab in GitHub.

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

How do I create a custom rerun check in Pipeline

Describe your use-case which is not covered by existing documentation.

Hello Team,

I am currently using the githubNotify plugin which helps create a status check in Github for my PR's

I wan to add a re-run to the above check. The github-checks-plugin seem to offer a re-run functionality as stated here.
https://plugins.jenkins.io/github-checks/#plugin-content-rerun-failed-build

Can you please advice on how to achieve this. The piece of code which enables the check during my pipeline run is as below.
githubNotify context: 'Master job status',
description: 'No jobs running',
status: 'SUCCESS',
gitApiUrl: 'https://github.com/api/v3'

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

1.7.5: download plugin checks-api to file: status code: 403, reason phrase: Forbidden

Jenkins and plugins versions report

Environment

jenkins/jenkins:2.319.3

What Operating System are you using (both controller, and any agents involved in the problem)?

Kubernetes

Reproduction steps

jenkins-plugin-cli --verbose \
    --war "$JENKINS_WAR" \
    --plugin-download-directory "$JENKINS_HOME/plugins" \
    --plugins "artifactory cloudbees-disk-usage-simple cloudbees-folder config-file-provider configuration-as-code credentials gerrit-trigger git mailer matrix-auth prometheus saml simple-theme-plugin ssh-slaves" \
    --latest "false"

Expected Results

checks-api 1.7.5 should be available at https://archives.jenkins.io/plugins/checks-api/1.7.5/checks-api.hpi

Actual Results

...
Downloaded gradle from https://mirror.gruenehoelle.nl/jenkins/plugins/gradle/1.39.4/gradle.hpi (attempt 1 of 3)
Downloaded and validated plugin gradle
Checksum valid for: gradle
Downloaded artifactory from https://mirror.gruenehoelle.nl/jenkins/plugins/artifactory/3.17.0/artifactory.hpi (attempt 1 of 3)
Downloaded and validated plugin artifactory
Checksum valid for: artifactory
Unable to resolve plugin URL https://archives.jenkins.io/plugins/checks-api/1.7.5/checks-api.hpi, or download plugin checks-api to file: status code: 403, reason phrase: Forbidden
io.jenkins.tools.pluginmanager.impl.DownloadPluginException: Unable to download checks-api
    at io.jenkins.tools.pluginmanager.impl.PluginManager.lambda$downloadPlugins$4(PluginManager.java:565)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
    at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
    at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
    at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Unable to download checks-api

Anything else?

Manually installing checks-api worked as it somehow resolved another endpoint to fetch it from.

# jenkins-plugin-cli --verbose --war "$JENKINS_WAR" --plugin-download-directory "$JENKINS_HOME/plugins" --plugins "checks-api" --latest "false"
...
Checksum valid for: script-security
Downloaded caffeine-api from https://mirror.gruenehoelle.nl/jenkins/plugins/caffeine-api/2.9.1-23.v51c4e2c879c8/caffeine-api.hpi (attempt 1 of 3)
Downloaded and validated plugin caffeine-api
Downloaded plugin-util-api from https://mirror.gruenehoelle.nl/jenkins/plugins/plugin-util-api/2.17.0/plugin-util-api.hpi (attempt 1 of 3)
Downloaded and validated plugin plugin-util-api
Checksum valid for: caffeine-api
Checksum valid for: plugin-util-api
Downloaded checks-api from https://ftp-nyc.osuosl.org/pub/jenkins/plugins/checks-api/1.7.5/checks-api.hpi (attempt 1 of 3)
Downloaded and validated plugin checks-api
Checksum valid for: checks-api
Done

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

github-actions

.github/workflows/ci.yml

• actions/checkout v4
• actions/setup-java v4
• stCarolas/setup-maven v5

.github/workflows/release-drafter.yml

• release-drafter/release-drafter v6

maven

.mvn/extensions.xml

• io.jenkins.tools.incrementals:git-changelist-maven-extension 1.8

pom.xml

• org.jvnet.hudson.plugins:analysis-pom 8.4.0
• org.testcontainers:testcontainers 1.19.8
• org.testcontainers:junit-jupiter 1.19.8

---

• Check this box to trigger a request for Renovate to run again on this repository

Include optional checks publisher to warnError

    The pattern I'd always intended to use with this (but never got round to implementing) was to add an optional checks publisher to `warnError`. For e.g. running tests you can do:

withChecks('My Tests') {
    sh 'run_tests > results.xml'
    junit 'results.xml'
}

and that works fine; sometimes you have a one-shot command where you just want to report success or failure. It would be nice to extend warnError to be checks aware:

withChecks('One Shot') {
    warnError('One Shot') {
        sh 'one_shot'
    }
}

ie, have warnError report the appropriate success/failure message to the active checks context.

Alternatively get warnError to be fully responsible for doing the checks itself, so

warnError(message: 'One Shot', publishChecks: true) {
    sh 'one_shot'
}

Not sure why I never got round to doing it, but happy to take another look if people think it might be a useful pattern?

Originally posted by @mrginglymus in #199 (comment)

Multiple Github repo's / global pipeline libraries how do we control the repo to which the checks are reported

Version report

Jenkins and plugins versions report:  
Jenkins: 2.2.89.3
Check API plugin: 1.7.2
Github Checks plugin: 1.0.13

• What Operating System are you using (both controller, and any agents involved in the problem)?

Paste here

Reproduction steps

• In a pipeline job use global pipeline libraries that are implicitly loaded
• This means the pipeline library is checked out without any user interaction
• In this case the checks seem to be going to the repo holding the pipeline library
• Also in general how do we control the repo to which the checks go when a job works with multiple git repos

[Question] Hanging checks with "withChecks()"

Hi,

I'm using Checks API plugin along with Github Checks API. According to the document, I wrote this code in my pipeline script:

steps {
    withChecks('CI/Main/CheckStyle') {
        // do stuff
        exit 1 // if error occured, the check will be completed with error  
         
        // But if everything is fine, no "COMPLETED" is published to the check, leave it forever hanging.
        // to solve this I'll have to manually do a publish 
        echo 'hello'
        publishChecks(name: 'CI/Main/CheckStyle', conclusion: 'SUCCESS', summary: 'Lint passed')
    }
}

The check is successfully published, but, as described above, I'll have to manually complete a check in my steps.

It seems the code didn't publish any checks in onSuccess on purpose.

I googled a lot for the usage of withChecks, no mention of this behavior. And examples on Github simply wrap normal steps without the manual complete.

I'm new to this, my usage could be wrong. Could someone help me with the correct usage of witchChecks? Appreciated!

[Checks API] No suitable checks publisher found.

Folks,

I am migrating to a new Jenkins instance. The previous one did not have the Checks API plugin installed, but the new one does.

I have a a job that is failing with the following error message:

Commit message: "Merge pull request #105 in ADS/itt from ibp-prod-updates to master"
Posting build status of INPROGRESS to NHLBI Bitbucket for commit id [db3c75841c2d6aef50cf95622890715a1c776234] and ref 'null'
[Checks API] No suitable checks publisher found

The pipeline never gets past the Declarative: Check, out SCM step. I don't think it is successfully completing the pull from git, so I don't think the job is even seeing the Jenkinsfile. The [Checks API] error is the last thing I see in the log before it goes to the Declarative: Post Actions, and the only obvious error in the log, so I figured I would start here to see there were any suggestions.

Thanks!

Tests fail on Java 21 with Mockito errors

The following Checks API tests fail on Java 21 with Mockito errors:

• io.jenkins.plugins.checks.api.ChecksPublisherFactoryTest
• io.jenkins.plugins.checks.api.NullChecksPublisherTest
• io.jenkins.plugins.checks.steps.PublishChecksStepTest
• io.jenkins.plugins.checks.steps.WithChecksStepTest

Similar issues have been observed in other plugins and were resolved by updating the plugin parent POM to 4.68 which has a recent version of Mockito that supports Java 21. Can this plugin be upgraded to a recent version of Mockito and a new version released for BOM/PCT purposes?

Bitbucket Server Implementation?

Are there any plans to add an implementation of this check api to the bitbucket branch source?
https://plugins.jenkins.io/cloudbees-bitbucket-branch-source/

Bitbucket has build status api, https://developer.atlassian.com/server/bitbucket/how-tos/updating-build-status-for-commits/ that might be similar enough to the Github Checks API

See also: https://jira.atlassian.com/browse/BSERV-11477

Check name should be configurable with a default rather than static

The Check Name is currently static. It would be very nice to be able to configure this, possibly with the current value of Jenkins as a default.

See:

checks-api-plugin/src/main/java/io/jenkins/plugins/checks/BuildStatusChecksPublisher.java

Line 36 in 0ee3cec

.withName(CHECKS_NAME)

Message "[Checks API] No suitable checks publisher found." started to appear in pipeline console output

Hello.
I've updated jenkins plugins today and looks like some of Pipeline plugins installed Checks API Plugin (version 1.0.2), which I didn't have installed.
Now in console output of pipeline jobs I see messages "[Checks API] No suitable checks publisher found." after I use git, and second time at the very end of pipeline. Pipelines work fine, I just get these messages.

Is there any way to suppress these messages, at least as an option?

checks not working for Bitbucket scm

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

rhel 8

Reproduction steps

running recordCoverage using Bitbucket as scm gives error

[Checks API] No suitable checks publisher found.

Expected Results

coverage should be published to bitbucket code insights

Actual Results

[Checks API] No suitable checks publisher found.

Anything else?

No response

Are you interested in contributing a fix?

Sure, with some guidance i can contribute to code, i can test it for integration with Bitbucket

Allow using specific credentials for Checks

What feature do you want to see added?

Currently, the Checks API uses the GitHub App credentials used to check out the code. We tested the GitHub Checks Plugin with one of our template pipelines (some linters, warningsNg, test coverage, etc.) and it consumed between 50-100 requests from the rate limit. Our rate limit is 15.000 / hour, so we could build ~150 builds per hour of this kind.
We provide a Jenkins instance for lots of users and rate limits are a serious issue. If the checks failed because the rate limit breaches, it wouldn't be such a big issue, but if the checks cause our rate limits to breach and as a result not even the checkouts work anymore, we definetly have an issue.
This could be solved by giving the possibility to define extra credentials for the checks plugin. This would decouple the rate limit of the checks from the more critical rate limit of checking out code.

This would also allow users to solve a security issue: If the App is no longer used to checkout code, it does no longer need permissions to the repository contents and could be reduced to having access to the Checks. In GitHub Enterprise, a GitHub App cannot be created by the user themself. We have to set it up and he can then add their own repository to it (limited to 100 repositories). This of course also grants all other users of the app access to his repository.

With the new feature, the user could use their own personal access token to checkout the code and use the GitHub App only for the checks.

Thanks for this plugin - it is very useful!

Upstream changes

No response

Feature Request: Option to NOT expose build logs

Dependencies

N.A.

Feature Request

The pipeline summary output (#66) is really a NEAT feature, thanks a lot for implementing it!

However in certain cases, it would be interesting to not expose the build's log output.

I'm thinking of the use case of a public code, but with the build output exposing sensitive information even it should not: if the build fails, then the sensitive data is exposed out of Jenkins.
Example which happened with Terraform: a bug in the 0.13.1 version was outputing sensitive data, which could have been exposed on the public repo.

The idea of this feature request can be splitted in 2 axes:

• Add an option to NOT add the build output in the summary (only the stage names, timing and statuses for instance)
• And/Or add an option to disable the pipeline summary when a GitHub MultiBranch / Organization job is used, to keep the benefit of the Check API without exposing sensitive information

Is this description clear or do you need more information/details?
If it is, does it seem legit?

.pom file uploaded for 1.7.1?

I that there's a .pom file uploaded for a version 1.7.1 but nothing else:
https://repo.jenkins-ci.org/releases/io/jenkins/plugins/checks-api/1.7.1/
And 1.7.0 is the latest release. What is the status of 1.7.1 and why has this .pom file been uploaded?
Best regards,
Lavina

Expose annotations to the publishChecks step

Add the ability to include annotations using the publishChecks step.

Here's the use case in a scripted pipeline, but in practice I would use a previously generated file for readJSON rather than text.

List issues = []
readJSON(text: '''[
    {
        'path': 'src/main/java/io/jenkins/plugins/checks/api/ChecksAnnotation.java', 
        'startLine': 5, 
        'endLine': 6, 
        'annotationLevel': 'NOTICE', 
        'message': 'you did something wrong', 
        'startColumn': 4, 
        'endColumn': 7, 
        'title': 'Bad thing', 
        'rawDetails': 'you did this specific thing wrong and you should fix it'
    }
]''').each {issue->
    issues.add(checksAnnotation(issue))  //checksAnnotation method would build and return a ChecksAnnotation object
}

publishChecks name: 'Check', title: 'Title', summary: 'Summary', text: 'Details', annotations: issues

Similar functionality for images and actions may be useful as well.

Rendering issues with pipeline information in 'Jenkins' check

e.g.

https://github.com/jenkinsci/google-oauth-plugin/runs/1864403011

I think multiple failures breaks it, I've seen it in a couple of places

fyi @mrginglymus

Local build doesn't fail for checkstyle or spotbugs

Pretty frustrating, what is your workflow for this @uhafer?

I run mvn clean install and then I create a PR and it fails for spotbugs or checkstyle

Add the ability to pass the credentialsId in the publishChecks step

Feature Request

Add the credentialsId argument to the publishChecks step (https://github.com/jenkinsci/checks-api-plugin#pipeline-usage). Then, it will be possible to use this feature explicitly in Jenkins jobs without changing the Job definition.

Why

IIUC, the only way to use this particular step is only when the GitHub App has been enabled in the Job level since GitHub checks are enabled on a GH App but no service accounts.

Further details

https://plugins.jenkins.io/pipeline-githubnotify-step/ enables to set a credentialsId instead using the one in the Job definition.

Fix flaky test `BuildStatusChecksPublisherITest.shouldPublishStageDetails`

When looking at the latest commits and closed PRs a lot of CI builds have been failed on Windows. We should make sure that this test does not produce false results.

Question: deterministic order of `ChecksPublisherFactory` execution

I am not sure if this will cause us a problem, but I'll ask in advance!

We are in the process of creating a custom extension of ChecksPublisherFactory, because the ones in the github-checks-plugin does not satisfy our usecase, even if we use github. We have GitSCM configured to checkout the Jenkinsfile from a repository, but we do not want to send the checks to that same repository. I see that the code below for the factory only takes the first valid publisher it finds. I was wondering what will happen if the two factories return a publisher.

Can we guarantee the order of the factories to make sure ours will be executed first ?

checks-api-plugin/src/main/java/io/jenkins/plugins/checks/api/ChecksPublisherFactory.java

Lines 96 to 105 in c83076d

	@VisibleForTesting
	static ChecksPublisher fromJob(final Job<?, ?> job, final TaskListener listener,
	final JenkinsFacade jenkinsFacade) {
	return findAllPublisherFactories(jenkinsFacade).stream()
	.map(factory -> factory.createPublisher(job, listener))
	.filter(Optional::isPresent)
	.map(Optional::get)
	.findFirst()
	.orElse(new NullChecksPublisher(createLogger(listener)));
	}

Setting Status checks name does not change it from the default Jenkins

Jenkins and plugins versions report

Environment

Jenkins: 2.401.3
OS: Linux - 5.10.178-162.673.amzn2.x86_64
Java: 11.0.19 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)
---
ace-editor:1.1
antisamy-markup-formatter:162.v0e6ec0fcfcf6
apache-httpcomponents-client-4-api:4.5.14-208.v438351942757
apache-httpcomponents-client-5-api:5.2.1-1.0
authentication-tokens:1.53.v1c90fd9191a_b_
aws-credentials:218.v1b_e9466ec5da_
aws-java-sdk:1.12.529-406.vdeff15e5817d
aws-java-sdk-cloudformation:1.12.529-406.vdeff15e5817d
aws-java-sdk-codebuild:1.12.529-406.vdeff15e5817d
aws-java-sdk-ec2:1.12.529-406.vdeff15e5817d
aws-java-sdk-ecr:1.12.529-406.vdeff15e5817d
aws-java-sdk-ecs:1.12.529-406.vdeff15e5817d
aws-java-sdk-efs:1.12.529-406.vdeff15e5817d
aws-java-sdk-elasticbeanstalk:1.12.529-406.vdeff15e5817d
aws-java-sdk-iam:1.12.529-406.vdeff15e5817d
aws-java-sdk-kinesis:1.12.529-406.vdeff15e5817d
aws-java-sdk-logs:1.12.529-406.vdeff15e5817d
aws-java-sdk-minimal:1.12.529-406.vdeff15e5817d
aws-java-sdk-secretsmanager:1.12.529-406.vdeff15e5817d
aws-java-sdk-sns:1.12.529-406.vdeff15e5817d
aws-java-sdk-sqs:1.12.529-406.vdeff15e5817d
aws-java-sdk-ssm:1.12.529-406.vdeff15e5817d
basic-branch-build-strategies:81.v05e333931c7d
bootstrap5-api:5.3.0-1
bouncycastle-api:2.29
branch-api:2.1122.v09cb_8ea_8a_724
build-timeout:1.31
caffeine-api:3.1.8-133.v17b_1ff2e0599
cdaas-agent-scaler:1.8.3
checks-api:2.0.0
cisco-spark-notifier:1.1.1
cloudbees-folder:6.848.ve3b_fd7839a_81
command-launcher:107.v773860566e2e
commons-lang3-api:3.13.0-62.v7d18e55f51e2
commons-text-api:1.10.0-68.v0d0b_c439292b_
config-file-provider:953.v0432a_802e4d2
copyartifact:722.v0662a_9b_e22a_c
credentials:1271.v54b_1c2c6388a_
credentials-binding:631.v861c06d062b_4
data-tables-api:1.13.5-1
datadog:5.5.0
display-url-api:2.3.9
docker-commons:439.va_3cb_0a_6a_fb_29
docker-java-api:3.3.1-79.v20b_53427e041
docker-workflow:572.v950f58993843
durable-task:523.va_a_22cf15d5e0
echarts-api:5.4.0-5
email-ext:2.100
envinject:2.908.v66a_774b_31d93
envinject-api:1.199.v3ce31253ed13
font-awesome-api:6.4.0-2
generic-webhook-trigger:1.87.0
git:5.2.0
git-client:4.4.0
git-server:99.va_0826a_b_cdfa_d
github:1.37.3
github-api:1.314-431.v78d72a_3fe4c3
github-branch-source:1732.v3f1889a_c475b_
github-checks:554.vb_ee03a_000f65
h2-api:11.1.4.199-12.v9f4244395f7a_
handlebars:3.0.8
htmlpublisher:1.32
instance-identity:173.va_37c494ec4e5
ionicons-api:56.v1b_1c8c49374e
jackson2-api:2.15.2-350.v0c2f3f8fc595
jakarta-activation-api:2.0.1-3
jakarta-mail-api:2.0.1-3
javadoc:243.vb_b_503b_b_45537
javax-activation-api:1.2.0-6
javax-mail-api:1.6.2-9
jaxb:2.3.8-1
jdk-tool:73.vddf737284550
jjwt-api:0.11.5-77.v646c772fddb_0
jnr-posix-api:3.1.17-1
jobConfigHistory:1227.v7a_79fc4dc01f
jquery3-api:3.7.0-1
jsch:0.2.8-65.v052c39de79b_2
junit:1217.v4297208a_a_b_ce
lockable-resources:1185.v0c528656ce04
mailer:463.vedf8358e006b_
mask-passwords:150.vf80d33113e80
matrix-auth:3.2
matrix-project:808.v5a_b_5f56d6966
maven-plugin:3.23
metrics:4.2.18-442.v02e107157925
mina-sshd-api-common:2.10.0-69.v28e3e36d18eb_
mina-sshd-api-core:2.10.0-69.v28e3e36d18eb_
momentjs:1.1.1
nodejs:1.6.1
notification:1.17
oic-auth:2.6
okhttp-api:4.11.0-157.v6852a_a_fa_ec11
permissive-script-security:0.7
pipeline-aws:1.43
pipeline-build-step:505.v5f0844d8d126
pipeline-github-lib:42.v0739460cda_c4
pipeline-graph-analysis:202.va_d268e64deb_3
pipeline-graph-view:198.v0844db_6ca_554
pipeline-groovy-lib:671.v07c339c842e8
pipeline-input-step:477.v339683a_8d55e
pipeline-maven:1322.v9ef317a_3e0a_9
pipeline-model-api:2.2144.v077a_d1928a_40
pipeline-model-definition:2.2144.v077a_d1928a_40
pipeline-model-extensions:2.2144.v077a_d1928a_40
pipeline-rest-api:2.33
pipeline-stage-step:305.ve96d0205c1c6
pipeline-stage-tags-metadata:2.2144.v077a_d1928a_40
pipeline-stage-view:2.33
pipeline-utility-steps:2.16.0
plain-credentials:143.v1b_df8b_d3b_e48
plugin-util-api:3.3.0
popper2-api:2.11.6-2
postbuildscript:3.2.0-460.va_fda_0fa_26720
publish-over:0.22
publish-over-ssh:1.25
rebuild:320.v5a_0933a_e7d61
resource-disposer:0.23
s3:0.12.3445.vda_704535b_5a_d
saferestart:0.7
scm-api:676.v886669a_199a_a_
script-security:1273.v66c1964f0dfd
snakeyaml-api:1.33-95.va_b_a_e3e47b_fa_4
sonar:2.15
ssh-credentials:308.ve4497b_ccd8f4
sshd:3.312.v1c601b_c83b_0e
structs:325.vcb_307d2a_2782
swarm:3.40
timestamper:1.26
token-macro:384.vf35b_f26814ec
tpsd-jenkins-plugin:3.0.4-SNAPSHOT (private-e699ebb8-rivanden)
trilead-api:2.84.v72119de229b_7
uno-choice:2.7.2
variant:59.vf075fe829ccb
workflow-api:1267.vd9b_a_ddd9eb_47
workflow-basic-steps:1042.ve7b_140c4a_e0c
workflow-cps:3773.v505e0052522c
workflow-durable-task-step:1289.v4d3e7b_01546b_
workflow-job:1326.ve643e00e9220
workflow-multibranch:756.v891d88f2cd46
workflow-scm-step:415.v434365564324
workflow-step-api:639.v6eca_cd8c04a_a_
workflow-support:848.v5a_383b_d14921
ws-cleanup:0.45

What Operating System are you using (both controller, and any agents involved in the problem)?

Ubuntu 20.04

Reproduction steps

1. Build > Configuration
2. Pipeline > Pipeline script from SCM > SCM: Git > Additional Behaviours > Status Checks Properties > Status checks name: tuneventd (instead of Jenkins, which was pre-populated) > Save
3. Run the Build

Expected Results

[GitHub Checks] GitHub check (name: tuneventd, status: in_progress) has been published.

Actual Results

[GitHub Checks] GitHub check (name: Jenkins, status: in_progress) has been published.

Anything else?

All other options for the Status Checks Properties have been left unchecked.

I am using Lightweight checkout for the project Jenkinsfile if that makes any difference.

publishChecks - how to publish a fail status?

Help wanted!

Great plugin, we use this in our pipeline. Is there a way to publish yellow dot (in progress) and red cross (fail) when using publishChecks? Below is the syntax we use, and all checks published have a green tick (screenshot for reference)

Syntax:
publishChecks(name: 'Jenkins/SBXDEPLOY Deploy', title: 'Cleanup - IN-PROGRESS', summary: '', text: '', detailsURL: "${JENKINS_URL}")

Phantom release 1.7.5 of checks-api

Jenkins and plugins versions report

Environment

junit:1119.1121.vc43d0fc45561

What Operating System are you using (both controller, and any agents involved in the problem)?

Jenkins LTS 2.346.x

Reproduction steps

1. jenkins-plugin-cli --no-download --verbose --plugins junit:1119.1121.vc43d0fc45561

Installed version (1.7.4) of checks-api is less than minimum required version of 1.7.5, bundled plugin will be upgraded

Expected Results

Use last available checks-api plugin version aka : 1.7.4

Actual Results

Try to use version 1.7.5 ( 404 not found)

Anything else?

No

Ability to add buttons in the publishChecks pipeline step

It would be nice to be able to add buttons to the publishChecks pipeline step.

Do not report handled exceptions

We're running our pipelines with a Jenkinsfile and a custom groovy-library that is tailored for our infrastructure. In this library we have defined a couple of exceptions to handle such cases to not immediately fail the pipeline

try {
...something that may fail
} catch(Exception e) {
...write to the log and handle the error
}

However, when looking at the GitHub check details these exceptions are still being reported. The picture below shows such a case where the java.nio.file.NoSuchFileException is gracefully handled by our library, but its still being reported as an error:

This is confusing for our users.

Version report

Jenkins and plugins versions report:

Jenkins: 2.289.2
OS: Linux - 4.15.0-147-generic
---
ace-editor:1.1
ansicolor:1.0.0
ant:1.11
antisamy-markup-formatter:2.1
apache-httpcomponents-client-4-api:4.5.13-1.0
artifactory:3.12.5
authentication-tokens:1.4
authorize-project:1.4.0
basic-branch-build-strategies:1.3.2
blueocean:1.24.8
blueocean-autofavorite:1.2.4
blueocean-bitbucket-pipeline:1.24.8
blueocean-commons:1.24.8
blueocean-config:1.24.8
blueocean-core-js:1.24.8
blueocean-dashboard:1.24.8
blueocean-display-url:2.4.1
blueocean-events:1.24.8
blueocean-executor-info:1.24.8
blueocean-git-pipeline:1.24.8
blueocean-github-pipeline:1.24.8
blueocean-i18n:1.24.8
blueocean-jira:1.24.8
blueocean-jwt:1.24.8
blueocean-personalization:1.24.8
blueocean-pipeline-api-impl:1.24.8
blueocean-pipeline-editor:1.24.8
blueocean-pipeline-scm-api:1.24.8
blueocean-rest:1.24.8
blueocean-rest-impl:1.24.8
blueocean-web:1.24.8
bootstrap4-api:4.6.0-3
bootstrap5-api:5.1.0-1
bouncycastle-api:2.21
branch-api:2.6.5
build-keeper-plugin:1.3
build-monitor-plugin:1.12+build.201809061734
caffeine-api:2.9.1-23.v51c4e2c879c8
checks-api:1.7.2
cloudbees-bitbucket-branch-source:2.9.10
cloudbees-disk-usage-simple:0.10
cloudbees-folder:6.16
command-launcher:1.6
conditional-buildstep:1.4.1
config-file-provider:3.8.1
configuration-as-code:1.51
copyartifact:1.46.1
credentials:2.5
credentials-binding:1.27
cvs:2.19
dark-theme:0.0.12
display-url-api:2.3.5
docker-commons:1.17
docker-java-api:3.1.5.2
docker-plugin:1.2.2
docker-workflow:1.26
durable-task:1.38
echarts-api:5.1.2-5
email-ext:2.83
extended-read-permission:3.2
external-monitor-job:1.7
favorite:2.3.3
font-awesome-api:5.15.3-4
generic-webhook-trigger:1.74
git:4.8.1
git-client:3.9.0
git-server:1.10
github:1.33.1
github-api:1.123
github-branch-source:2.11.2
github-checks:1.0.13
github-scm-trait-notification-context:1.1
global-slack-notifier:1.5
google-oauth-plugin:1.0.6
gradle:1.37.1
handlebars:3.0.8
handy-uri-templates-2-api:2.1.8-1.0
htmlpublisher:1.25
http_request:1.10
icon-shim:3.0.0
ivy:2.1
jackson2-api:2.12.4
javadoc:1.6
jdk-tool:1.5
jenkins-design-language:1.24.8
jira:3.5
jjwt-api:0.11.2-9.c8b45b8bb173
job-dsl:1.77
jobConfigHistory:2.28.1
jquery:1.12.4-1
jquery-detached:1.2.1
jquery3-api:3.6.0-2
jsch:0.1.55.2
junit:1.51
kubernetes:1.30.1
kubernetes-client-api:5.4.1
kubernetes-credentials:0.9.0
label-linked-jobs:6.0.1
ldap:2.7
lockable-resources:2.11
login-theme:1.1
mailer:1.34
mapdb-api:1.0.9.0
material-theme:0.4.1
matrix-auth:2.6.8
matrix-project:1.19
maven-plugin:3.12
mercurial:2.15
metrics:4.0.2.8
momentjs:1.1.1
multibranch-scan-webhook-trigger:1.0.9
multiple-scms:0.8
next-build-number:1.6
oauth-credentials:0.4
okhttp-api:3.14.9
pam-auth:1.6
parameterized-trigger:2.41
pipeline-build-step:2.15
pipeline-github:2.7
pipeline-graph-analysis:1.11
pipeline-input-step:2.12
pipeline-milestone-step:1.3.2
pipeline-model-api:1.9.1
pipeline-model-definition:1.9.1
pipeline-model-extensions:1.9.1
pipeline-rest-api:2.19
pipeline-stage-step:2.5
pipeline-stage-tags-metadata:1.9.1
pipeline-stage-view:2.19
pipeline-utility-steps:2.8.0
plain-credentials:1.7
plot:2.1.9
plugin-util-api:2.4.0
popper-api:1.16.1-2
popper2-api:2.9.3-1
prometheus:2.0.10
pubsub-light:1.16
purge-build-queue-plugin:1.0
rebuild:1.32
run-condition:1.5
saferestart:0.3
saml:2.0.8
scm-api:2.6.5
script-security:1.78
sidebar-link:1.12.0
simple-theme-plugin:0.7
skip-notifications-trait:1.0.5
slack:2.48
snakeyaml-api:1.29.1
sse-gateway:1.24
ssh:2.6.1
ssh-agent:1.23
ssh-credentials:1.19
ssh-slaves:1.32.0
sshd:3.1.0
structs:1.23
subversion:2.14.4
theme-manager:0.6
token-macro:266.v44a80cf277fd
translation:1.16
trilead-api:1.0.13
variant:1.4
windows-slaves:1.8
workflow-aggregator:2.6
workflow-api:2.46
workflow-basic-steps:2.23
workflow-cps:2.93
workflow-cps-global-lib:2.21
workflow-durable-task-step:2.39
workflow-job:2.41
workflow-multibranch:2.26
workflow-scm-step:2.13
workflow-step-api:2.24
workflow-support:3.8

• What Operating System are you using (both controller, and any agents involved in the problem)?

Controller is unkown (x86+linux)
Agent is RHEL 7.5

Reproduction steps

• Jenkinsfile with

node('nodename') {
  stage('name') {
    try {
      readFile(file: 'testfile')
    } catch (Exception e) {
      //nothing to see here
      print("cannot find it, so what")
    }
  }
}

• Run the Jenkinsfile

Results

Expected result:

Check report success and nothing else ( since the pipeline handled the error)

Actual result: