Problem.report_job_log.py only ever commented on an open pull
request. A push-triggered job -- the shape of a publish pipeline, which has
no pull_request trigger at all -- has none: the branch pushed to is the
merge's target, not the already-closed PR that produced it. Combined with
job logs returning 500 on this Gitea, that made a push-triggered failure
completely invisible. Real cost: weblib-viewer run 1769 (publish, push on development) failed after ~12.5 minutes and posted nothing anywhere;
diagnosing it needed a throwaway commit hardcoding --pr 27 just to get the
log somewhere visible. Filed as #14.
What I checked first. A GitHub-style commit-comment endpoint
(commits/{sha}/comments) does not exist on this Gitea: 404, and it is
absent from /swagger.v1.json entirely -- not a permissions or path issue,
the route simply is not registered. Ruled out with the swagger dump, not
just the one probe #14 already had.
What actually works, verified live against git.chaosbit.de:
GET repos/{repo}/commits/{sha}/pull resolves the PR that produced a given
commit, open or closed, keyed on the exact commit rather than a branch
name. Checked against both merge styles this org uses: an explicit merge
commit (weblib-ci#13 -> 8c00889...) and a fast-forward promotion, where
the "merge commit" is just the PR branch's own tip (weblib-fs#27 -> 1aaad66...). Both resolved to the right PR number. It needs the full
40-character sha -- a short one gets the identical 404 shape as a commit
with no PR at all, so truncating it would silently look like "nothing
found" rather than erroring loudly.
POST repos/{repo}/statuses/{sha} (commit status) is the fallback for the
residual case: a commit that was never part of any PR. Verified it accepts
a long description unmodified (3000 chars round-tripped exactly), and did
a full live run of the actual script against this repo -- see below.
What changed. Before giving up, report_job_log.py now tries the
sha-based PR lookup after the existing event-payload and branch-name lookups.
If a PR is found (open or closed), behaviour is identical to before: the
same comment, same format. Only when no PR exists anywhere for the commit
does it fall back to a commit status -- shorter (STATUS_TAIL, 500
characters, truncated from the log tail) and less discoverable than a
comment, but not silence. state follows the reported outcome
(failed→failure, passed→success, cancelled→warning, skipped→skipped; an unrecognised status maps to error rather than
guessing pass or fail), and target_url points at the commit.
No CLI changes -- existing callers (all four consumer repos) are unaffected;
the whole thing is additive to the environment-variable-driven path they
already use.
Verification:
python3 test_report_job_log.py: 28/28 (was 22/22; +6 new tests
covering the sha-lookup success case, ordering -- branch lookup still wins
when it applies -- the commit-status fallback with the outcome-to-state
mapping, the no-sha/no-PR dead end not crashing, and that the ordinary pull_request-event path is untouched).
Live smoke test of the real script (not the offline fake) against this
repo, this branch's own tip commit (c2947db0, which has no PR yet):
resolved to "no PR anywhere" and posted a real commit status -- state: success, correct description and target_url, confirmed by
reading it back via the API. That status is visible on this PR's own head
commit.
Not done: the "reuse/dedup an issue" option from #14 was not built -- the
sha lookup turned out to cover the actual failure case (a push is almost
always a merge landing) well enough that the noisier issue-based fallback
didn't seem worth the complexity. Worth revisiting only if a repo here ever
pushes commits that were never part of any PR as routine practice.
**Problem.** `report_job_log.py` only ever commented on an *open* pull
request. A `push`-triggered job -- the shape of a publish pipeline, which has
no `pull_request` trigger at all -- has none: the branch pushed to is the
merge's *target*, not the already-closed PR that produced it. Combined with
job logs returning 500 on this Gitea, that made a push-triggered failure
completely invisible. Real cost: weblib-viewer run 1769 (`publish`, `push` on
`development`) failed after ~12.5 minutes and posted nothing anywhere;
diagnosing it needed a throwaway commit hardcoding `--pr 27` just to get the
log somewhere visible. Filed as #14.
**What I checked first.** A GitHub-style commit-comment endpoint
(`commits/{sha}/comments`) does **not exist** on this Gitea: 404, and it is
absent from `/swagger.v1.json` entirely -- not a permissions or path issue,
the route simply is not registered. Ruled out with the swagger dump, not
just the one probe #14 already had.
**What actually works, verified live against `git.chaosbit.de`:**
- `GET repos/{repo}/commits/{sha}/pull` resolves the PR that produced a given
commit, **open or closed**, keyed on the exact commit rather than a branch
name. Checked against both merge styles this org uses: an explicit merge
commit (weblib-ci#13 -> `8c00889...`) and a fast-forward promotion, where
the "merge commit" is just the PR branch's own tip (weblib-fs#27 ->
`1aaad66...`). Both resolved to the right PR number. It needs the **full**
40-character sha -- a short one gets the identical 404 shape as a commit
with no PR at all, so truncating it would silently look like "nothing
found" rather than erroring loudly.
- `POST repos/{repo}/statuses/{sha}` (commit status) is the fallback for the
residual case: a commit that was never part of any PR. Verified it accepts
a long description unmodified (3000 chars round-tripped exactly), and did
a full live run of the actual script against this repo -- see below.
**What changed.** Before giving up, `report_job_log.py` now tries the
sha-based PR lookup after the existing event-payload and branch-name lookups.
If a PR is found (open or closed), behaviour is **identical to before**: the
same comment, same format. Only when no PR exists anywhere for the commit
does it fall back to a commit status -- shorter (`STATUS_TAIL`, 500
characters, truncated from the log tail) and less discoverable than a
comment, but not silence. `state` follows the reported outcome
(`failed`→`failure`, `passed`→`success`, `cancelled`→`warning`,
`skipped`→`skipped`; an unrecognised status maps to `error` rather than
guessing pass or fail), and `target_url` points at the commit.
No CLI changes -- existing callers (all four consumer repos) are unaffected;
the whole thing is additive to the environment-variable-driven path they
already use.
**Verification:**
- `python3 test_report_job_log.py`: **28/28** (was 22/22; +6 new tests
covering the sha-lookup success case, ordering -- branch lookup still wins
when it applies -- the commit-status fallback with the outcome-to-state
mapping, the no-sha/no-PR dead end not crashing, and that the ordinary
`pull_request`-event path is untouched).
- Live smoke test of the real script (not the offline fake) against this
repo, this branch's own tip commit (`c2947db0`, which has no PR yet):
resolved to "no PR anywhere" and posted a real commit status --
`state: success`, correct description and `target_url`, confirmed by
reading it back via the API. That status is visible on this PR's own head
commit.
**Not done:** the "reuse/dedup an issue" option from #14 was not built -- the
sha lookup turned out to cover the actual failure case (a push is almost
always a merge landing) well enough that the noisier issue-based fallback
didn't seem worth the complexity. Worth revisiting only if a repo here ever
pushes commits that were never part of any PR as routine practice.
Closes #14
report_job_log.py only ever commented on an open PR, so a push to
development/main -- the shape of a publish pipeline, which has no
pull_request trigger -- had nowhere to post: the branch pushed to is the
merge's target, not the already-closed PR that produced it. Combined with
job logs 500ing on this Gitea, that made a push-triggered failure completely
invisible (weblib-viewer run 1769, diagnosed only by hardcoding --pr on a
throwaway commit).
A GitHub-style commit-comment endpoint, the first thing tried, does not
exist on this Gitea: 404, and absent from /swagger.v1.json entirely. What
does exist and was verified live: GET commits/{sha}/pull resolves the PR
that produced a given commit, open or closed, across both merge styles this
org uses -- so the closed PR the push actually came from can still be found
and commented on as before. When even that finds nothing (a commit that was
never part of any PR), fall back to a commit status, since that endpoint is
already proven to work here.
No CLI changes; existing callers are unaffected.
Closes#14
Co-authored-by: bit <bit@das-labor.org>
claude
requested review from bit 2026-09-10 10:47:13 +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
Problem.
report_job_log.pyonly ever commented on an open pullrequest. A
push-triggered job -- the shape of a publish pipeline, which hasno
pull_requesttrigger at all -- has none: the branch pushed to is themerge's target, not the already-closed PR that produced it. Combined with
job logs returning 500 on this Gitea, that made a push-triggered failure
completely invisible. Real cost: weblib-viewer run 1769 (
publish,pushondevelopment) failed after ~12.5 minutes and posted nothing anywhere;diagnosing it needed a throwaway commit hardcoding
--pr 27just to get thelog somewhere visible. Filed as #14.
What I checked first. A GitHub-style commit-comment endpoint
(
commits/{sha}/comments) does not exist on this Gitea: 404, and it isabsent from
/swagger.v1.jsonentirely -- not a permissions or path issue,the route simply is not registered. Ruled out with the swagger dump, not
just the one probe #14 already had.
What actually works, verified live against
git.chaosbit.de:GET repos/{repo}/commits/{sha}/pullresolves the PR that produced a givencommit, open or closed, keyed on the exact commit rather than a branch
name. Checked against both merge styles this org uses: an explicit merge
commit (weblib-ci#13 ->
8c00889...) and a fast-forward promotion, wherethe "merge commit" is just the PR branch's own tip (weblib-fs#27 ->
1aaad66...). Both resolved to the right PR number. It needs the full40-character sha -- a short one gets the identical 404 shape as a commit
with no PR at all, so truncating it would silently look like "nothing
found" rather than erroring loudly.
POST repos/{repo}/statuses/{sha}(commit status) is the fallback for theresidual case: a commit that was never part of any PR. Verified it accepts
a long description unmodified (3000 chars round-tripped exactly), and did
a full live run of the actual script against this repo -- see below.
What changed. Before giving up,
report_job_log.pynow tries thesha-based PR lookup after the existing event-payload and branch-name lookups.
If a PR is found (open or closed), behaviour is identical to before: the
same comment, same format. Only when no PR exists anywhere for the commit
does it fall back to a commit status -- shorter (
STATUS_TAIL, 500characters, truncated from the log tail) and less discoverable than a
comment, but not silence.
statefollows the reported outcome(
failed→failure,passed→success,cancelled→warning,skipped→skipped; an unrecognised status maps toerrorrather thanguessing pass or fail), and
target_urlpoints at the commit.No CLI changes -- existing callers (all four consumer repos) are unaffected;
the whole thing is additive to the environment-variable-driven path they
already use.
Verification:
python3 test_report_job_log.py: 28/28 (was 22/22; +6 new testscovering the sha-lookup success case, ordering -- branch lookup still wins
when it applies -- the commit-status fallback with the outcome-to-state
mapping, the no-sha/no-PR dead end not crashing, and that the ordinary
pull_request-event path is untouched).repo, this branch's own tip commit (
c2947db0, which has no PR yet):resolved to "no PR anywhere" and posted a real commit status --
state: success, correct description andtarget_url, confirmed byreading it back via the API. That status is visible on this PR's own head
commit.
Not done: the "reuse/dedup an issue" option from #14 was not built -- the
sha lookup turned out to cover the actual failure case (a push is almost
always a merge landing) well enough that the noisier issue-based fallback
didn't seem worth the complexity. Worth revisiting only if a repo here ever
pushes commits that were never part of any PR as routine practice.
Closes #14
report_job_log.py only ever commented on an open PR, so a push to development/main -- the shape of a publish pipeline, which has no pull_request trigger -- had nowhere to post: the branch pushed to is the merge's target, not the already-closed PR that produced it. Combined with job logs 500ing on this Gitea, that made a push-triggered failure completely invisible (weblib-viewer run 1769, diagnosed only by hardcoding --pr on a throwaway commit). A GitHub-style commit-comment endpoint, the first thing tried, does not exist on this Gitea: 404, and absent from /swagger.v1.json entirely. What does exist and was verified live: GET commits/{sha}/pull resolves the PR that produced a given commit, open or closed, across both merge styles this org uses -- so the closed PR the push actually came from can still be found and commented on as before. When even that finds nothing (a commit that was never part of any PR), fall back to a commit status, since that endpoint is already proven to work here. No CLI changes; existing callers are unaffected. Closes #14 Co-authored-by: bit <bit@das-labor.org>