jenkinsci / checks-api-plugin Goto Github PK
View Code? Open in Web Editor NEWJenkins plugin that defines an API for Jenkins to publish checks to SCM platforms.
Home Page: https://plugins.jenkins.io/checks-api/
License: MIT License
Jenkins plugin that defines an API for Jenkins to publish checks to SCM platforms.
Home Page: https://plugins.jenkins.io/checks-api/
License: MIT License
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.
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
Controller is unkown (x86+linux)
Agent is RHEL 7.5
node('nodename') {
stage('name') {
try {
readFile(file: 'testfile')
} catch (Exception e) {
//nothing to see here
print("cannot find it, so what")
}
}
}
Expected result:
Check report success and nothing else ( since the pipeline handled the error)
Actual result:
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.
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.
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
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
...
Docker image for the controller and linux and macos agents
sh(label: "Test", script: "false")
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
)
No error is shown in the summary and the details lists the step without an error.
I think the problem is in
It should probably prioritize the error check even if it has a name.
I'd be willing to make a PR, but I'm not sure about the original intentions of the code.
N.A.
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:
Is this description clear or do you need more information/details?
If it is, does it seem legit?
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?
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.
:(
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
Ubuntu 20.04
[GitHub Checks] GitHub check (name: tuneventd, status: in_progress) has been published.
[GitHub Checks] GitHub check (name: Jenkins, status: in_progress) has been published.
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.
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.
No response
No response
It would be nice to be able to add buttons to the publishChecks
pipeline step.
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!
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?)
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.
No response
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.
No response
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
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!
No response
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()
}
}
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
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?
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 ?
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
.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
.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
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}")
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?
No response
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:
#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).
Unstable builds contains test failures and should be marked as failed
See
https://gitter.im/jenkinsci/warnings-plugin?at=5f32ff4d4c89605c7f8d6b27
cc @XiongKezhi
This line here:
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.
junit:1119.1121.vc43d0fc45561
Jenkins LTS 2.346.x
Installed version (1.7.4) of checks-api is less than minimum required version of 1.7.5, bundled plugin will be upgraded
Use last available checks-api plugin version aka : 1.7.4
Try to use version 1.7.5 ( 404 not found)
No
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'
No response
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.
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.
https://plugins.jenkins.io/pipeline-githubnotify-step/ enables to set a credentialsId instead using the one in the Job definition.
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!
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.
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
jenkins/jenkins:2.319.3
Kubernetes
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"
checks-api 1.7.5 should be available at https://archives.jenkins.io/plugins/checks-api/1.7.5/checks-api.hpi
...
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
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
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)
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.
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:
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)
Jenkins and plugins versions report:
Jenkins: 2.2.89.3
Check API plugin: 1.7.2
Github Checks plugin: 1.0.13
Paste here
Paste the output here
rhel 8
running recordCoverage using Bitbucket as scm gives error
[Checks API] No suitable checks publisher found.
coverage should be published to bitbucket code insights
[Checks API] No suitable checks publisher found.
No response
Sure, with some guidance i can contribute to code, i can test it for integration with Bitbucket
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.