[rush] Design: "Timeline" Output for rush build

[elliot-nelson]

Summary

Recapping results of discussion at the tail end of the phased builds demo in the Jan 7 Rush Hour meeting.

We looked at both David's --trace PR #2569, and also my ASCII timeline PR #3139.

Details

During the meeting I think it became clear that there are 2 different interests in a "timeline":

(1) Reporting

Either after a local build, or while looking at a CI build, you may want to examine what happened during a build and when. Both the trace and ASCII PRs are examples of this approach.

It might be interesting to have a new "build result JSON" format, that could be an output of a rush build, and could be consumed to produce either a chrome trace or the ASCII chart or an HTML report etc. etc. So instead of producing the ASCII timeline at the end of rush build, it might be more like:

rush build
rush analyze --ascii temp/build.json

# Alternately: rush analyze --html to view it as a cool web page, etc.
# Maybe rush analyze --chrome to convert it into trace data and open your web browser?
# If desired, your CI pipeline could build and analyze in sequence so the ASCII output is in your build log

(If the trace format has enough data in it to fully represent all the info we'd want out of the timeline, then we could adopt that as the standard.)

(2) An enhancement of the build output

This approach is more about redesigning the "in progress" view of a local rush build to show cool interactive ASCII charts. I'll admit, my primary interest is the CI analysis, but this is also an interesting idea.

David had a similar concept in #2300 (comment), where he proposed replacing the bottom of the build log with interactive progress bars for each running phase, so you could see what % of compilation had finished, what % of testing, and so on. (With today's output continuing to scroll into stdout "above" the interactive progress info).

There's a lot of cool things we could do here, but probably use (2) is separate from use (1) -- one is about displaying a set of data as a report, and the other is about how best to show the user what we're doing during a rush build.

Standard questions

Please answer these questions to help us investigate your issue more quickly:

Question	Answer
@microsoft/rush globally installed version?
rushVersion from rush.json?
useWorkspaces from rush.json?
Operating system?
Would you consider contributing a PR?	Yes
Node.js version (node -v)?

[dlannoye]

When I first set "telemetryEnabled": true in my rush.json I was hoping for output to have enough detail to enable building my own tooling to visualize a build timeline and start seeing more insights like what the new build timeline feature is enabling. For my use case the new build timeline would probably end up being un-usable with the number of packages I have locally, but having access to the data in a JSON format would be great.

For my tool to date, I have been scraping the package build times off the summary messages and then feeding them through a script that knows the dependency graph to generate a timeline of tasks that doesn't take into account CPU placement, but is still helpful for uncovering why builds end up taking as long as they do.

[elliot-nelson]

I think this highlights a current design flaw.

Probably, the output of telemetryEnabled should be updated and enhanced so that the JSON files contains everything you'd need to build that ASCII chart. And, the chart itself should be able to be generated by rush timeline --json <telemetry.json>. This would allow you to also build in other features, e.g., rush timeline --json <telemetry.json> --width 320 for display on a big curved monitor.

We could still have rush build --timeline, it would just be spitting out telemetry JSON and then running rush timeline at the end of the build. But you could choose to run the two commands separate, or replace rush timeline with your own custom chart solution.