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

[JEP-210] Log handling rewrite #15

Merged
merged 55 commits into from
Oct 4, 2018
Merged

Conversation

jglick
Copy link
Member

@jglick jglick commented Sep 23, 2016

Downstream of jenkinsci/workflow-api-plugin#17. Subsumes #75.

JEP-210

  • basics
  • fix rendering of console output from Pipeline Steps
  • way to efficiently get all output from a branch
  • retain compatibility if only this plugin is updated and not workflow-job
  • optimize AnnotatedLogAction.getLogText
  • optimize AnnotatedLogAction.strip

@jglick
Copy link
Member Author

jglick commented Sep 23, 2016

Not going to bother deploying upstream snapshots at this stage, so CI failures are expected.

@jglick jglick changed the title [JENKINS-38381] Log handling rewrite [JEP-210] Log handling rewrite Aug 6, 2018
@svanoort
Copy link
Member

svanoort commented Aug 8, 2018

@jglick Does this fix the issue we discussed months ago where it requires reading the entire logfile to retrieve the fragment for a single step?

@jglick
Copy link
Member Author

jglick commented Aug 8, 2018

reading the entire logfile to retrieve the fragment for a single step

That has since been refactored into jenkinsci/workflow-api-plugin#17 where it now lives in StreamLogStorage.stepLog. Since streaming a single file is relatively cheap for I/O, and the filtering is simple, that is just left as is to keep things simple. Of course if you are using, e.g., CloudWatch Logs there is a completely different implementation (in that case using server-side filtering).

Rendering speed is anyway not a priority for JEP-210, compared to optimizing writing during the build. (discussion)

* A marker for a node which had some log text.
*/
@Restricted(NoExternalUse.class) // for use from DefaultStepContext only
public class AnnotatedLogAction extends LogAction implements FlowNodeAction, PersistentAction {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be renamed.

@dwnusbaum dwnusbaum self-requested a review August 15, 2018 21:09
public static @Nonnull TaskListener listenerFor(@Nonnull FlowNode node, @CheckForNull ConsoleLogFilter filter) throws IOException, InterruptedException {
FlowExecutionOwner owner = node.getExecution().getOwner();
if (LogActionImpl.isOld(owner) || node.getAction(LogActionImpl.class) != null) {
return LogActionImpl.stream(node, filter);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably the !FlowNode.active closing logic from LogActionImpl should be moved here—for some implementations it may be significant (though not for FileLogStorage). Also rather than PrintStream.close it should check for TaskListener & AutoCloseable. And the expected close behavior for both the overall and step logs should be documented in LogStorage.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(resolved)

@Override public void onNewHead(FlowNode newNode) {
if (!node.isActive()) {
node.getExecution().removeListener(this);
LOGGER.log(Level.FINE, "closing log for {0}", node.getDisplayFunctionName());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a good time, try to disentangle what all the xxFunctionName/xxDisplayName function for a FlowNode do and which to use when.

And by a "good time" I mean "if you're a masochist."

@@ -97,6 +99,33 @@
}
}

private synchronized TaskListener getListener() throws IOException, InterruptedException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Synchronizing is /probably/ the right move here but makes me nervous we're going to hit threading issues (as has happened with analogous changes in WorkflowRun with bottlenecks and deadlocks). Nothing I can point to explicitly wrong here, but something to keep a close eye on.

…e is expected, send it to the overall build log not the step log.

This allows us to call context.get(EnvVars.class) even on a FlowNode which has not yet been attached to the graph.
…e is expected, send it to the overall build log not the step log.

This allows us to call context.get(EnvVars.class) even on a FlowNode which has not yet been attached to the graph.

(cherry picked from commit d5d1f46)
@jglick jglick merged commit 0dfa35c into jenkinsci:master Oct 4, 2018
@jglick jglick deleted the logs-JENKINS-38381 branch October 4, 2018 20:54
@@ -62,17 +67,14 @@
if (key == EnvVars.class) {
Run<?,?> run = get(Run.class);
EnvironmentAction a = run == null ? null : run.getAction(EnvironmentAction.class);
EnvVars customEnvironment = a != null ? a.getEnvironment() : run.getEnvironment(get(TaskListener.class));
EnvVars customEnvironment = a != null ? a.getEnvironment() : run.getEnvironment(getExecution().getOwner().getListener());
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amended in #62 FTR.

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