One of the next targets on my personal checks-api hitlist was input steps - automatically setting
ACTION_REQUIREDwhen 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
- Implement an input listener (does one even exist?) in
checks-apiand 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)
GitHubChecksActionshould 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"
QUEUEDstatus checks with the
IN_PROGRESSchecks for pipeline jobs as we won't have anywhere to store that information, but I think that's reasonable.
if-elseblock 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
withChecksblocks and then adds a corresponding action to the
run. That means the checks plugin can decide on its own if the
nameof 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
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).
publisher.forceName, you mean after this invocation, all checks (published by consumers' or
publishChecksstep) should all use the name specified in
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
Is that right? And if so, what runes do I need to allow for
LogStorage still being in beta?