Nothing needed from you right now -- filing this so it is not lost, found
while diagnosing weblib-viewer#26's publish-pipeline fallout.
What happened
fdroid-dev.yml runs report_job_log.py on if: failure(), same pattern as
every other consumer. weblib-viewer's PR#27 merged to development, and the
resulting push run (task id 1769, sha c9d6db67) failed after ~12.5
minutes. report_job_log.py ran (its own if: failure() guard fired) but
posted no comment anywhere -- repos/weblib/weblib-viewer/issues/27/comments
stayed empty even though #27 was the PR that had just introduced the change.
Job logs return 500 on this Gitea (the whole reason this script exists), so
that failure was otherwise completely invisible: no comment, no readable log,
nothing.
Why, by the script's own logic
pull_request_for_branch() is given GITHUB_HEAD_REF or GITHUB_REF_NAME as branch, then looks for an open PR whose head.ref equals it. For a push event on development, that branch is literally development -- the
branch pushed to, not the feature branch that was just merged and whose PR
is now closed. No open PR has head.ref == "development", so pull_request_for_branch correctly returns None, and the script does
exactly what its own docstring says: "A push to a branch with no PR still has
nowhere to comment, which is honest: there is no thread for it."
So this is not a bug in the branch-lookup logic -- it is working as designed,
and that design is right for an ordinary test/CI workflow where nobody is
watching a closed PR after merge. It stops being right for a publish
workflow that runs on every push to development/main and has no
subsequent PR to attach to: a failure there currently has zero readable
channels -- not the log (500), not a PR comment (no open PR), nothing. I only
found this run's actual failure by hardcoding --pr <known number> on a
throwaway debug commit and re-dispatching, which is not a diagnostic anyone
should have to reach for on every red push.
Confirmed working: the workflow_dispatch path
For contrast, dispatching the same workflow manually against a branch that
still has an open PR does get a comment -- pull_request_for_branch
correctly resolved weblib-viewer#27 from GITHUB_REF_NAME for two workflow_dispatch runs (ids 1767, 1773) while that PR was open. The gap is
specifically: event is push, and there is no open PR for the pushed branch
at all (the common case for development/main, since a push there usually
means a PR just merged and closed).
Not proposing a fix here
Options that come to mind, none evaluated: comment on the PR that most
recently merged into the pushed branch (needs a commit-to-PR lookup, which
Gitea may or may not expose cheaply); fall back to opening/commenting on a
standing "CI status" issue for push-triggered failures; or accept the gap and
document it as a known blind spot for anyone adding a push-triggered publish
workflow. Leaving the call to whoever picks this up -- filing it now so the
gap is on record rather than rediscovered the next time a post-merge publish
fails silently.
Nothing needed from you right now -- filing this so it is not lost, found
while diagnosing weblib-viewer#26's publish-pipeline fallout.
## What happened
`fdroid-dev.yml` runs `report_job_log.py` on `if: failure()`, same pattern as
every other consumer. weblib-viewer's PR#27 merged to `development`, and the
resulting `push` run (task id 1769, sha `c9d6db67`) failed after ~12.5
minutes. `report_job_log.py` ran (its own `if: failure()` guard fired) but
posted **no comment anywhere** -- `repos/weblib/weblib-viewer/issues/27/comments`
stayed empty even though #27 was the PR that had just introduced the change.
Job logs return 500 on this Gitea (the whole reason this script exists), so
that failure was otherwise completely invisible: no comment, no readable log,
nothing.
## Why, by the script's own logic
`pull_request_for_branch()` is given `GITHUB_HEAD_REF` or `GITHUB_REF_NAME` as
`branch`, then looks for an **open** PR whose `head.ref` equals it. For a
`push` event on `development`, that branch is literally `development` -- the
branch pushed *to*, not the feature branch that was just merged and whose PR
is now closed. No open PR has `head.ref == "development"`, so
`pull_request_for_branch` correctly returns `None`, and the script does
exactly what its own docstring says: "A push to a branch with no PR still has
nowhere to comment, which is honest: there is no thread for it."
So this is not a bug in the branch-lookup logic -- it is working as designed,
and that design is right for an ordinary test/CI workflow where nobody is
watching a closed PR after merge. It stops being right for a **publish**
workflow that runs on every push to `development`/`main` and has no
subsequent PR to attach to: a failure there currently has *zero* readable
channels -- not the log (500), not a PR comment (no open PR), nothing. I only
found this run's actual failure by hardcoding `--pr <known number>` on a
throwaway debug commit and re-dispatching, which is not a diagnostic anyone
should have to reach for on every red push.
## Confirmed working: the workflow_dispatch path
For contrast, dispatching the same workflow manually against a branch that
still has an **open** PR *does* get a comment -- `pull_request_for_branch`
correctly resolved weblib-viewer#27 from `GITHUB_REF_NAME` for two
`workflow_dispatch` runs (ids 1767, 1773) while that PR was open. The gap is
specifically: event is `push`, and there is no open PR for the pushed branch
at all (the common case for `development`/`main`, since a push there usually
means a PR just merged and closed).
## Not proposing a fix here
Options that come to mind, none evaluated: comment on the PR that most
recently merged into the pushed branch (needs a commit-to-PR lookup, which
Gitea may or may not expose cheaply); fall back to opening/commenting on a
standing "CI status" issue for push-triggered failures; or accept the gap and
document it as a known blind spot for anyone adding a push-triggered publish
workflow. Leaving the call to whoever picks this up -- filing it now so the
gap is on record rather than rediscovered the next time a post-merge publish
fails silently.
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.
Nothing needed from you right now -- filing this so it is not lost, found
while diagnosing weblib-viewer#26's publish-pipeline fallout.
What happened
fdroid-dev.ymlrunsreport_job_log.pyonif: failure(), same pattern asevery other consumer. weblib-viewer's PR#27 merged to
development, and theresulting
pushrun (task id 1769, shac9d6db67) failed after ~12.5minutes.
report_job_log.pyran (its ownif: failure()guard fired) butposted no comment anywhere --
repos/weblib/weblib-viewer/issues/27/commentsstayed empty even though #27 was the PR that had just introduced the change.
Job logs return 500 on this Gitea (the whole reason this script exists), so
that failure was otherwise completely invisible: no comment, no readable log,
nothing.
Why, by the script's own logic
pull_request_for_branch()is givenGITHUB_HEAD_REForGITHUB_REF_NAMEasbranch, then looks for an open PR whosehead.refequals it. For apushevent ondevelopment, that branch is literallydevelopment-- thebranch pushed to, not the feature branch that was just merged and whose PR
is now closed. No open PR has
head.ref == "development", sopull_request_for_branchcorrectly returnsNone, and the script doesexactly what its own docstring says: "A push to a branch with no PR still has
nowhere to comment, which is honest: there is no thread for it."
So this is not a bug in the branch-lookup logic -- it is working as designed,
and that design is right for an ordinary test/CI workflow where nobody is
watching a closed PR after merge. It stops being right for a publish
workflow that runs on every push to
development/mainand has nosubsequent PR to attach to: a failure there currently has zero readable
channels -- not the log (500), not a PR comment (no open PR), nothing. I only
found this run's actual failure by hardcoding
--pr <known number>on athrowaway debug commit and re-dispatching, which is not a diagnostic anyone
should have to reach for on every red push.
Confirmed working: the workflow_dispatch path
For contrast, dispatching the same workflow manually against a branch that
still has an open PR does get a comment --
pull_request_for_branchcorrectly resolved weblib-viewer#27 from
GITHUB_REF_NAMEfor twoworkflow_dispatchruns (ids 1767, 1773) while that PR was open. The gap isspecifically: event is
push, and there is no open PR for the pushed branchat all (the common case for
development/main, since a push there usuallymeans a PR just merged and closed).
Not proposing a fix here
Options that come to mind, none evaluated: comment on the PR that most
recently merged into the pushed branch (needs a commit-to-PR lookup, which
Gitea may or may not expose cheaply); fall back to opening/commenting on a
standing "CI status" issue for push-triggered failures; or accept the gap and
document it as a known blind spot for anyone adding a push-triggered publish
workflow. Leaving the call to whoever picks this up -- filing it now so the
gap is on record rather than rediscovered the next time a post-merge publish
fails silently.