Since weblib-archive#44 there is no such file in any consuming repo — the
script lives here. So it pointed a reader at a path they cannot find, at the
one moment they are already hunting for the cause of a failure. Now links here.
How it was found, because the method matters more than the fix. I added the
reporter to weblib-fs (#31 there) and did not merge on green: a green run never
executes if: failure(), so merging would have shipped an untested failure
path — the same shape as a skip reading as a pass. So I deliberately broke that
build, watched the reporter post, and reverted. The stale path was visible only
in that posted comment.
Also notes in the module docstring that this script is consumed from other
repos, so its output must not name paths inside the repo it is reporting on.
The comment `report_job_log.py` posts said:
> posted by `tools/report_job_log.py`
Since weblib-archive#44 there is no such file in any consuming repo — the
script lives here. So it pointed a reader at a path they cannot find, at the
one moment they are already hunting for the cause of a failure. Now links here.
**How it was found, because the method matters more than the fix.** I added the
reporter to weblib-fs (#31 there) and did not merge on green: a green run never
executes `if: failure()`, so merging would have shipped an untested failure
path — the same shape as a skip reading as a pass. So I deliberately broke that
build, watched the reporter post, and reverted. The stale path was visible only
in that posted comment.
Also notes in the module docstring that this script is consumed from other
repos, so its output must not name paths inside the repo it is reporting on.
The comment it posts said "posted by `tools/report_job_log.py`". Since
weblib-archive#44 there is no such file in any consuming repo -- the script
lives here. So it pointed a reader at a path they cannot find, on the one
occasion they are already looking for the cause of a failure.
Links here instead.
Found by deliberately breaking a build on weblib-fs#31 to prove the failure
path worked. A green run never renders this message, so nothing else would
have surfaced it.
Co-authored-by: bit <bit@das-labor.org>
claude
requested review from bit 2026-09-07 12:15:08 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
bit
The comment
report_job_log.pyposts said:Since weblib-archive#44 there is no such file in any consuming repo — the
script lives here. So it pointed a reader at a path they cannot find, at the
one moment they are already hunting for the cause of a failure. Now links here.
How it was found, because the method matters more than the fix. I added the
reporter to weblib-fs (#31 there) and did not merge on green: a green run never
executes
if: failure(), so merging would have shipped an untested failurepath — the same shape as a skip reading as a pass. So I deliberately broke that
build, watched the reporter post, and reverted. The stale path was visible only
in that posted comment.
Also notes in the module docstring that this script is consumed from other
repos, so its output must not name paths inside the repo it is reporting on.