jenkinsci / jenkinsci/checks-api-plugin

Enhancement: Allow mapping ABORTED builds to SKIPPED check conclusion

Open
#331 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
49
Forks
32
Avg merge
2d 5h
Merged PRs (30d)
5

Description

### What feature do you want to see added?

### Description
I am using the Checks API plugin in a Jenkins pipeline and running into an issue where an aborted build incorrectly reports a `FAILURE` status to GitHub instead of `SKIPPED`.

### Context & Use Case
In our Jenkins pipeline, the first stage evaluates specific conditions to determine if the build should proceed. If the conditions are not met, we intentionally abort the pipeline using:
```groovy
currentBuild.result = 'ABORTED'
```
We use this approach to signal that a job was skipped rather than failed.

### The Problem
Currently, the Checks API plugin maps an `ABORTED` build to a `CANCELED` check conclusion:
https://github.com/jenkinsci/checks-api-plugin/blob/fa7f8da1d543a110c571679fe2db9d272f10af68/src/main/java/io/jenkins/plugins/checks/status/BuildStatusChecksPublisher.java#L152-L154

When the Jenkins pipeline finishes after being aborted, the automatic final check is published with a `FAILURE` status.

I tried to manually override this by adding a `publishChecks` step in that first stage right before the pipeline ends:
```groovy
publishChecks(
name: 'Jenkins',
status: 'COMPLETED',
conclusion: 'SKIPPED',
title: 'Jenkins job',
summary: 'Job aborted'
)
```
While this manually published check triggers successfully during execution, it gets completely overwritten by the plugin's default finalization logic once the build fully completes, reverting the status back to `FAILURE`.

### Question
Is it currently possible to configure the Jenkins Checks API plugin to map an ABORTED build status to a SKIPPED GitHub check conclusion? Alternatively, can we manually publish a check outcome from within the pipeline without the plugin overriding it once the build finishes?

If not, could this be considered as a feature request similarly to how it was done for `UNSTABLE` builds in [Issue #46](https://github.com/jenkinsci/checks-api-plugin/issues/46)?

### Upstream changes

_No response_

### Are you interested in contributing this feature?

_No response_

Contributor guide

Open the contributing guide

Research direction

Start with src/main/java/io/jenkins/plugins/checks/status/BuildStatusChecksPublisher.java around lines 152-154, then compare the existing UNSTABLE handling referenced in Issue #46. Verify how finalization maps an ABORTED build and overwrites manually published checks; done means an ABORTED build produces a SKIPPED check conclusion without being reverted to FAILURE.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, java
Domain
api, ci-cd
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
62/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.