Nice, I need to pick a better target file but this does work. You can see the failure in 769bd71 when I reduced to baseline time to 0.2.

Was just thinking - I imagine that as things are now, it may be hard to debug the workflow when it fails as it may not be clear on what timing it failed.
Could be an idea to:

• first run the report in a separate step and store the report to $GITHUB_OUTPUT.
• In a next step to echo out the report for debug purposes
• Then in the step after that use grep to get the timing target from the report.

Good thinking! I got that to work, I believe, although I still had to collect the output, print it, and grep it in the same step because I can't figure out how to pass a multi-line github output variable through grep. I figured out how to store the multi-line output in an output variable but then echoing it back into a unix pipe seems very difficult 🤔 . Hopefully a single step will be ok for now.

although I still had to collect the output, print it, and grep it in the same step because I can't figure out how to pass a multi-line github output variable through grep

I cheated and dumped the output to a file. That works.

@sirbrillig Nicely done ;-)