GitHub Checks API for Jenkins Plugins. https://www.jenkins.io/projects/gsoc/2020/projects/github-checks/
Thanks for getting it out the door :)
you want to do it?
all seems fine
@uhafner , in warnings-ng plugin,
I saw many custom and pre-defined jelly files or tags (e.g. resource/issues folder) that have been reused in the plugin.
I'm trying to avoid repeating my self by pre defining some custom jelly files,
but when I'm tyring to do it by setting the property xmlns:i="/some/path/to/jelly/files" like this line,
the jelly files can be parsed correctly and the IDE prompts "URI is not registered",
do I miss anything besides setting the custom jelly files folder?
the folder path also needs to be globally unique, the normal pattern is:
lib/your-plugin-name/file.jelly
or there is only jenkins to github ?
Still getting zombie jobs on agents. Final stack trace on console was:
00:32:24.679 hudson.AbortException: Pull request 5852 : Not mergeable at xxxxxxxx+xxxxxxxxxxxx (NOT_MERGEABLE)
00:32:24.679 at org.jenkinsci.plugins.github_branch_source.PullRequestSCMRevision.validateMergeHash(PullRequestSCMRevision.java:106)
00:32:24.679 at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.retrieve(GitHubSCMSource.java:1599)
00:32:24.679 at jenkins.scm.api.SCMSource.fetch(SCMSource.java:582)
00:32:24.679 at io.jenkins.plugins.checks.github.SCMFacade.findRevision(SCMFacade.java:156)
00:32:24.679 Caused: java.lang.IllegalStateException: Could not fetch revision from repository: xxxxxxxxxxxx
00:32:24.679 at io.jenkins.plugins.checks.github.SCMFacade.findRevision(SCMFacade.java:159)
00:32:24.679 at io.jenkins.plugins.checks.github.GitHubSCMSourceChecksContext.resolveHeadSha(GitHubSCMSourceChecksContext.java:131)
00:32:24.679 at io.jenkins.plugins.checks.github.GitHubSCMSourceChecksContext.<init>(GitHubSCMSourceChecksContext.java:46)
00:32:24.679 at io.jenkins.plugins.checks.github.GitHubSCMSourceChecksContext.fromRun(GitHubSCMSourceChecksContext.java:24)
00:32:24.679 at io.jenkins.plugins.checks.github.GitHubChecksPublisherFactory.createPublisher(GitHubChecksPublisherFactory.java:42)
00:32:24.679 at io.jenkins.plugins.checks.api.ChecksPublisherFactory.lambda$fromRun$0(ChecksPublisherFactory.java:89)
...
00:32:24.679 at io.jenkins.plugins.checks.api.ChecksPublisherFactory.fromRun(ChecksPublisherFactory.java:92)
00:32:24.679 at io.jenkins.plugins.checks.api.ChecksPublisherFactory.fromRun(ChecksPublisherFactory.java:69)
00:32:24.679 at io.jenkins.plugins.checks.steps.WithChecksStep$WithChecksStepExecution.publish(WithChecksStep.java:150)
00:32:24.679 at io.jenkins.plugins.checks.steps.WithChecksStep$WithChecksStepExecution.access$100(WithChecksStep.java:83)
00:32:24.679 at io.jenkins.plugins.checks.steps.WithChecksStep$WithChecksStepExecution$WithChecksCallBack.onStart(WithChecksStep.java:169)
I note we potentially have a similar issue in
onFailure; it feels like at least the publish invocation should be in a try/catch per the TailCall example implementation of BodyExecutionCallback
But then I have no idea how the plumbing of any of this works :shrug:
So the timeline i think was, i force push to master, new run starts but before the milestone step can abort it we kick off a with checks execution on the old job. That explodes trying to publish the start check because merge conflict, which means the body execution throws wihthout calling context.onFailure. The overall job stop, but the agents seem to still think theyre doing something.
ill chuck up a pr later today to explain
I've raised jenkinsci/github-branch-source-plugin#386 as I think this may be where the underlying specific issue is
I'm much less sure how to deal with the general problem of hardening
BodyExecutionCallback against runtime exceptions
I'm also undecided as to whether I think that https://github.com/jenkinsci/github-checks-plugin/blob/d376cd617d6060c000e9e3b5e680770014ec1968/src/main/java/io/jenkins/plugins/checks/github/SCMFacade.java#L158-L161 should just return
Optional.empty() rather than re-throwing. I certainly think it should rethrow a checked exception at the very least; but given we're just a glorified logger it seems unhelpful to bring down the entire execution...
jenkinsci/workflow-step-api-plugin#60 <- a PR containing a test case demonstrating the general issue
No idea how to fix it yet :D
or should i ask this in the warnings-ng plugin chat?
And annotations are just shown on the files page.
Well I'm stumped on the test failures on jenkinsci/checks-api-plugin#93 - my computer + jenkins CI are happy; one of the github ones seems to always fail. Tried adding
-X to see if I could get more info...and it passed D:
still failed https://github.com/jenkinsci/checks-api-plugin/runs/2067201799, not sure what's the problem. But it does pass after I merged it and re-run all builds: https://github.com/jenkinsci/checks-api-plugin/runs/2064256739 @mrginglymus
Thanks all for the great plugin! Had a presentation about Advanced Code Coverage in Jenkins today with overview of Code Coverage API and GitHub Checks integrations. Was happy to present our GSoC and to do live demos from ci.jenkins.io. https://twitter.com/oleg_nenashev/status/1400524585464963074