fix(release): fetch file SHAs from base branch, not next-release #24

2026-05-13T11:09:37Z

argoyle commented

2026-05-13 11:09:37 +00:00

Why

After #23, the workflow on robotframework failed with CHANGELOG.md write failed after 5 attempts (422): {"message":"repository file already exists [path: CHANGELOG.md]"}.

Sequence from the log:

POST /branches → 201 (branch created).
GET /branches/next-release → 500, 500, then 200 (the readiness poll worked).
fetch_sha then queried GET /contents/CHANGELOG.md?ref=next-release immediately after — that endpoint was still propagating and didn't return the SHA, so fetch_sha came back empty.
write_file saw no SHA, used POST (create), and got HTTP 422 because the file genuinely existed on base (and therefore on the freshly forked next-release).

Different Gitea API endpoints don't share a single readiness signal for a newly created branch — /branches can report ready while /contents is still 500/404.

Changes

fetch_sha now queries ?ref=${BASE_BRANCH} instead of ?ref=next-release. Base is stable, and Gitea content writes are content-addressed by blob SHA, so a SHA fetched from main works for PUT on next-release (it was just forked from main, so the blob is identical).
Treat 404 as "file absent, no SHA" and retry other non-200 responses up to 5× with backoff.

Test plan

Trigger Release.yml on robotframework (or another repo with an existing CHANGELOG.md on main). Confirm CHANGELOG.md and .version both write via PUT first try, and PR is created.
First-release repo (no CHANGELOG.md on main yet): fetch_sha returns empty after 404, write_file POSTs to create — confirm this path still works.

## Why After #23, the workflow on `robotframework` failed with `CHANGELOG.md write failed after 5 attempts (422): {"message":"repository file already exists [path: CHANGELOG.md]"}`. Sequence from the log: - `POST /branches` → 201 (branch created). - `GET /branches/next-release` → 500, 500, then 200 (the readiness poll worked). - `fetch_sha` then queried `GET /contents/CHANGELOG.md?ref=next-release` immediately after — that endpoint was still propagating and didn't return the SHA, so `fetch_sha` came back empty. - `write_file` saw no SHA, used POST (create), and got HTTP 422 because the file genuinely existed on base (and therefore on the freshly forked `next-release`). Different Gitea API endpoints don't share a single readiness signal for a newly created branch — `/branches` can report ready while `/contents` is still 500/404. ## Changes - `fetch_sha` now queries `?ref=${BASE_BRANCH}` instead of `?ref=next-release`. Base is stable, and Gitea content writes are content-addressed by blob SHA, so a SHA fetched from main works for PUT on `next-release` (it was just forked from main, so the blob is identical). - Treat 404 as "file absent, no SHA" and retry other non-200 responses up to 5× with backoff. ## Test plan - [ ] Trigger Release.yml on `robotframework` (or another repo with an existing CHANGELOG.md on main). Confirm CHANGELOG.md and .version both write via PUT first try, and PR is created. - [ ] First-release repo (no CHANGELOG.md on main yet): `fetch_sha` returns empty after 404, `write_file` POSTs to create — confirm this path still works.

argoyle added 1 commit 2026-05-13 11:09:38 +00:00

fix(release): fetch file SHAs from base branch, not next-release e07c8412f0

After POST /branches reports 201 and GET /branches/next-release reports
200, the /contents/{path}?ref=next-release endpoint can still 500 or
404 transiently while Gitea finishes indexing the new branch. That
caused fetch_sha to return empty for files that actually existed on
base, so write_file fell back to POST (create) and got HTTP 422
"repository file already exists" five times before giving up.

Query base branch for the blob SHA instead. Base is stable, and Gitea
content writes are content-addressed by blob SHA, so a SHA fetched from
main works for PUT on next-release (next-release was just forked from
main, so the blob is identical). Treat 404 as "file absent" and retry
other non-200 responses up to 5 times.

argoyle merged commit 1f9d754f61 into main

2026-05-13 11:10:46 +00:00

argoyle deleted branch fix-release-fetch-sha-from-base

2026-05-13 11:10:46 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unboundsoftware/shared-workflows#24