GSoC 2020 - GitHub Checks API for Jenkins Plugins. https://www.jenkins.io/projects/gsoc/2020/projects/github-checks/
One of the next targets on my personal checks-api hitlist was input steps - automatically setting
ACTION_REQUIRED
when input is requested, and resolving with details of input provided. However, I wasn't quite sure how to slice this. I could see three ways (dependent on what APIs are actually available...)
- Add a 'checksName' to
input
inpipeline-input-step
- Make
pipeline-input-step
withChecksName
aware- Implement an input listener (does one even exist?) in
checks-api
and let that do the heavy lifting
it's better to let other plugins dependent on the check API to resolve the context themselves not the other way around IMO
java.lang.UnsupportedOperationException
at java.util.Collections$UnmodifiableCollection.add(Collections.java:1057)
at hudson.model.Actionable.addAction(Actionable.java:155)
at io.jenkins.plugins.checks.github.GitHubChecksContext.addActionIfMissing(GitHubChecksContext.java:127)
at io.jenkins.plugins.checks.github.GitHubChecksPublisher.publish(GitHubChecksPublisher.java:78)
at io.jenkins.plugins.checks.status.BuildStatusChecksPublisher.publish(BuildStatusChecksPublisher.java:38)
at io.jenkins.plugins.checks.status.BuildStatusChecksPublisher.access$100(BuildStatusChecksPublisher.java:32)
at io.jenkins.plugins.checks.status.BuildStatusChecksPublisher$JobCheckoutListener.onCheckout(BuildStatusChecksPublisher.java:124)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:579)
Caused: java.io.IOException
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:581)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1880)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:428)
GitHubChecksAction
should not be an job- or project-wise action, it should be a run- or build-wise one.
I'm just popping out for a walk but - it looks like we can make GitHubChecksContext always accept a run (promoting from GitSCMChecksContext) and accept that in some limited circumstances it may be null.
As far as I can tell that'll only be when it's created because of a 'queued' listener.
We then hook our actions onto the Run, not the Job, and if we don't have a Run we just say "Sorry, don't know what the ID is"
QUEUED
status checks with the IN_PROGRESS
checks for pipeline jobs as we won't have anywhere to store that information, but I think that's reasonable.
if-else
block to check for a context object and set the name accordingly. Wouldn’t it be smarter if that decision would be solely made by the checks plugins? As far as I understand the current implementation the checks API looks for withChecks
blocks and then adds a corresponding action to the run
. That means the checks plugin can decide on its own if the name
of the consumer should be used or the name that is part of the action.
As far as I understand the current implementation the checks API looks for withChecks blocks and then adds a corresponding action to the run.
I don't think that's right - it adds a POJO to the body invoker context, which is going to be difficult (impossible?) to get when we create or invoke a publisher.
The action is not added to the run
but to the StepContext
which is only visible in the withChecks
block.
I think the initial reason why we introduced it is that: if there are parallel stages or multiple stages in a pipeline, for example, and they both invokes publishIssues
for PMD report, these reports will be mixed in a single check run (or worse if the implementation didn't provide update mechanism, the later one will just overwrite the former). The solution can be:
the warnings-ng plugin or other consumer plugins add a field to allow user specific the name (maybe for each tool in warnings-ng).
Provide the withChecks
step.
publisher.forceName
, you mean after this invocation, all checks (published by consumers' or publishChecks
step) should all use the name specified in forName
step?
I'm trying to work out the correct way to get build logs for a step - as far as I can tell it's something like:
LogStorage logStorage = LogStorage.of(flowNode.getExecution().getOwner());
AnnotatedLargeText<FlowNode> logText = logStorage.stepLog(flowNode, true);
and then do the necessary BAOS wrangling on logText
.
Is that right? And if so, what runes do I need to allow for LogStorage
still being in beta?
flowNode.getAction(LogAction.class).getLogText()
?