[rush] Experimental: task runner ASCII timeline generator #3139
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Once the upcoming "phased builds" feature is rolled out, monorepo maintainers will want to try it out. I think there's two big questions that will get asked: (1) am I configuring these phases correctly? (2) am I getting enough value out of this extra configuration?
Being able to see visually what was built can often highlight questions to go explore in your own configuration, and some additional summary details can highlight what changes you might want to make to the structure of projects in the repo to get better performance out of your phases.
Details
This PR currently writes out a simple text file to contain the additional graph, but that's actually not ideal, because what you really want as a maintainer is to notice a build that had a long duration yesterday, click on it, and see what happened in the timeline. So maybe a
--timeline
option that spits it out at the end of the build to stdout would be preferred.Example sanitized outputs:
Alternate approaches
An alternate approach (maybe technically better) would be #2569. However, to use this, you really need to configure your pipelines ahead of time to always trace and always save the trace artifact as a build output, otherwise you won't have it when you need it. (Maybe that PR might add "--trace", and it could generate the ASCII graph in addition to the event format output?)
How it was tested