POC for better metrics gathering from build_runner

[alan-knight]

Proof of concept form jam work Feb 2022. We would like to be able to get some more information out of build_runner and how long things take. At a minimum, we'd like to be able to get the information that is printed to stdout. However, it's hard to capture that without disrupting the nice terminal display of the build progress. This is a POC of that.

The way build_runner works is that the executable does almost nothing but cause generation of the build script, and then execute that script. And the API call to generate the script takes a function that generates it. So we can make a very stripped-down version of that executable, and invoke that instead of the build_runner. It can generate its own build script, which it does by taking the regular build script and injecting a log listener that writes to a file. Then we can read that file back and we have the log information.

• This is against 3.7.1 because the newer version has prerequisites that can't be used against any of our packages yet.
• It's only done for the test command.
• Passing the extra information up and down in dart_dev is not easy. We pass information in a CommandResult, but we only construct that very high up, in DartDevRunner.run. There are Command objects, but they are fairly transient, as are the ExecutionContext and Execution, and it's all fairly hard-coded that the only return value is a single integer for the exit code. However, the runner does store instances of each Command. So we can make a temporary file name in that instance and have access to it at the runner level, as long as we do our own separate parse of the arguments to find the command.
• Then we can pass it as an argument to the tweaked script (bypassing regular arg parsing right now) and we can embed it into the generated script. (This is probably not a good idea, because it makes the build script change every time, but it seemed simpler than adding arg parsing to the generated build script).
• The build script seems to change anyway, because if we use test, it ends up in build_runner test logic, which checks if the build script has changed (I think) and then regenerates it and does another build in the middle of the tests running. I may be wrong about why that's happening. One possible approach is the other POC, for a TDD mode, running dart test separately from build_runner build. Or it may be more directly fixable.
• The method for generating the temporary file name is not pretty.
• I seem to have trouble creating a pull request against an old tag, so this is against head, which means it pulls in some junk changes, which will need to be sorted out, but it should be pretty clear.

[aviary-wf]

Security Insights

No security relevant content was detected by automated scans.

Action Items

• Review PR for security impact; comment "security review required" if needed or unsure
• Verify aviary.yaml coverage of security relevant code

---

Questions or Comments? Reach out on Slack: #support-infosec.