Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-45693] Calling TaskListenerDecorator #105

Merged
merged 72 commits into from
Oct 4, 2018

Conversation

jglick
Copy link
Member

@jglick jglick commented Sep 5, 2018

JENKINS-45693, more or less.

Subsumes #27. Downstream of jenkinsci/workflow-api-plugin#76 & jenkinsci/workflow-support-plugin#72.

Originally in JENKINS-30777, @kohsuke attempted in jenkinsci/jenkins#1833 to make ConsoleLogFilters registered globally as @Extensions applicable to WorkflowRun. He only defined a new method signature, though, and did not call it from workflow-job, so on its own this did nothing. In fact among the known implementations few are actual extensions:

ConsoleLogFilter could not actually work for interesting use cases: as noted in TaskListenerDecorator Javadoc, that API would make it physically impossible to define a global filter which was both compatible with JEP-210 remote logging and took into account which build’s output it was decorating, because the injection of the Run context occurs “at the last minute” and this context is not remotable. So rather than applying ConsoleLogFilter.all, this set of PRs uses a new API designed with these use cases in mind. As the examples above show, this approach is more backwards compatible, and there are no existing extensions which would have benefitted anyway. ConsoleLogFilter may however continue to be used contextually, which plenty of plugins do (withCredentials is a good example).

#66 and jenkinsci/workflow-support-plugin#57 both attempted to address something like JENKINS-45693. This PR supersedes both.

Unfortunately it is also necessary to <exclude> the official dependency GAs to avoid duplication,
which seems like a fundamental limitation of jitpack.io as applied to Maven.
…tep logs, even for steps running across the upgrade.

In this example, log is complete and the raw log is identical to what it would have been without an upgrade;
the first echo step and the sleep step use LogActionImpl and have complete *.log files;
the second echo step uses LogStorageAction and log-index records its range.
@svanoort
Copy link
Member

Note: approval contingent on fixes to the upstream PR(s) and their approval.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants