Two behaviours landed in #4 that the one-line description did not mention, and
both are the kind of thing someone debugging would want to know before reading
the source:
* the label is resolved from the repo *or the organisation* - labels moved to
the org on 2026-09-07, and resolving from the repo alone is what silently
turned the whole script into a no-op
* an issue marked Status/On Hold or Status/Abandoned is left entirely alone,
neither labelled nor unlabelled
Co-authored-by: bit <bit@das-labor.org>
The seed commit said `uses:` did not work. That was measured while this repo
was private and is no longer true: with the full URL it works, and the action's
outputs.path reaches the caller and can run the tools.
The bare owner/repo form still fails - it resolves against the instance default
actions URL, not this host - so the README says which to use and why, with the
per-form results.
Co-authored-by: bit <bit@das-labor.org>
Split out of the four repos per weblib-archive#44. All three files were
byte-identical across every repo at this moment, which will not stay true --
they converged only because four twin PRs landed within hours today, and
report_job_log.py had already drifted once before that.
Taken from weblib-archive, verified identical to every other copy first:
with-nixpkgs.sh ca43fa20 (cfbypass, archive, fs)
report_job_log.py aaef8f62 (cfbypass, archive)
sync_blocked_label.py e6ddb21d (all four)
action.yml is included so the `uses:` question can be re-measured now the repo
is public; it did not work while private.
Co-authored-by: bit <bit@das-labor.org>
