Found when this workflow fired for the first time since it was written (a path filter on fpga/openxc7-synth/** woke it).
SUCCESS_RATE comes from grep -oP '\d+\.\d+(?=%)' | tail -1, falling back to counting PASS/OK/✅ tokens against PASS/FAIL/ERROR tokens in free-form test output. That measures the shape of the log, not the state of the project — and on the very first run, two matrix entries executing the identical script disagreed (aware IMMORTAL, transcendent MORTAL), which is proof enough that the number is not reproducible.
Changed to report rather than block, with the reasoning in the workflow. The design question is yours: if the threshold should gate merges, the metric needs to be a count the harness emits deliberately (e.g. a machine-readable summary line), not one a grep infers. Two other defects in the same workflow are fixed alongside: a step testing a file present in no commit, and a PR-comment step missing pull-requests: write.
Found when this workflow fired for the first time since it was written (a path filter on
fpga/openxc7-synth/**woke it).SUCCESS_RATEcomes fromgrep -oP '\d+\.\d+(?=%)' | tail -1, falling back to counting PASS/OK/✅ tokens against PASS/FAIL/ERROR tokens in free-form test output. That measures the shape of the log, not the state of the project — and on the very first run, two matrix entries executing the identical script disagreed (awareIMMORTAL,transcendentMORTAL), which is proof enough that the number is not reproducible.Changed to report rather than block, with the reasoning in the workflow. The design question is yours: if the threshold should gate merges, the metric needs to be a count the harness emits deliberately (e.g. a machine-readable summary line), not one a grep infers. Two other defects in the same workflow are fixed alongside: a step testing a file present in no commit, and a PR-comment step missing
pull-requests: write.