Web/UI: Folding large build logs

[YoussB]

What challenge are you facing?

• With some builds having a lot of logs being loaded, Job page can sometimes become huge and there is a good chance of missing some important information especially in failed builds.

What would make this better?

• I saw this nice feature under prow when running a build.
• Simply it folds build logs lines keeping only the lines that contain errors
• would be nice if we implement something similar, to allow us to see through the logs.

Let me know what you think?

[marco-m]

Yes! FYI Also TravisCI offers the same folding by default.

[YoussB]

@marco-m didn't know that. It is super useful!

[jamieklassen]

I'd like to have more specific criteria for

keeping only the lines that contain errors

as it's not totally clear to me from this example.

If I had to guess, I'd say that this example is folding everything, but keeping 5 lines of context around any log line containing the word 'error'. I don't think we can reasonably assume that this is either necessary or sufficient to be considered "important information" in an arbitrary Concourse task.

Another option would be to have 5 lines of context unfolded around any logs to stderr, but this causes trouble in the case of resources, since they can only output logs to stderr as part of the resource contract.

Finally, perhaps simplest (and the only well-defined option I can think of) would be to do a slightly more dramatic version of what currently happens -- any successful steps are collapsed, and any erroring steps are expanded, but we could further fold all but the last few lines of an erroring step.

@YoussB do you have any more context on how prow decides what to fold, or @marco-m any suggestion about how TravisCI folds by default? @Lindsayauchin

[marco-m]

@pivotal-jamie-klassen I got confused, it is travis-ci that folds by default :-) An example of travis folding is https://travis-ci.org/marco-m/QSyncthingTray/jobs/231902538. An example of circle ci is https://circleci.com/gh/RobustPerception/PushProx/21.

I also agree this is difficult to get right. I think it is more important to get scrolling performance always fast, such as in #3521.

[vito]

@marco-m Agreed - we should be careful that this change isn't motivated by performance concerns, because folding won't fix the bottleneck. That should all be tracked in #3521. 👍

[YoussB]

@vito I am not sure if this would be possible, what if the folded part is not loaded from the db until unfold is clicked? 🤔

@pivotal-jamie-klassen I agree with the erroring steps Vs. successful ones. From he looks of prow it looks like it is filtering by the word error and adding 5 lines before and after.

[vito]

@YoussB Unfortunately we don't even know where the line boundaries are because events are stored as arbitrary chunks of data. More on that in #3521 (comment)

[kallisti5]

At minimum could you "show the last XX lines of the task first?"

We have long builds (cross-compile gcc) and the output kills client browsers. Tailing the last 50 lines (with a "view all" option) would at least cut down on data.

[marco-m]

@kallisti5 I am not sure "show the last XX lines of the task first?" is possible, vito explains why just above. As a workaorund, remember that you can always use fly watch and bypass the browser completely.

[kallisti5]

@marco-m telling users to "use the cli" really isn't a great solution or workaround :-)

As a temporary solution, what if we keep the currently running task "unexpanded" by default? The responsiveness greatly improves when concourse doesn't expand the text of the currently task by default.

[marco-m]

We have different definitions of "workaround" then. I am proposing you a workaround that you can use now. Feel free to propose a PR.

[kallisti5]

My PR (#3894) kind of sucked since I don't have a ton of knowledge on the templating engine used.

fly watch definitely shows the logs in real time better than the web ui, however for an open source project with 100's of people contributing, asking them all to install fly isn't realistic... thus using fly to look at logs isn't a realistic workaround.

Now, once the build completes the web ui works as expected. It seems the "sending all the logs over and over, and redrawing them" is what really kills the performance.

Is there a way to "slow down the reload of the logs proportionate to the log file size" as a short-term workaround?