fix(release): make Release.yml robust to curl exit codes #23

2026-05-13T10:53:01Z

argoyle commented

2026-05-13 10:53:01 +00:00

Why

After #22 moved the branch-readiness poll before .version write, the workflow started failing every run with exitcode '23' and no error output. Exit 23 = CURLE_WRITE_ERROR from curl in the wait loop's BRANCH_STATUS=$(curl ...). With set -e, any non-zero status from a command substitution aborts the script before the retry/echo path runs — so the failure was both deterministic and silent.

Changes

Introduce an api_call helper that wraps curl with || rc=$? and emits <http_code>|<curl_rc> plus the response body. Curl exit codes can no longer kill the script via set -e.
Create the next-release branch explicitly via POST /branches instead of relying on the new_branch parameter of the CHANGELOG.md PUT. Eliminates the race between branch creation and subsequent file writes.
Poll branch readiness after explicit creation.
Fetch file blob SHAs from next-release directly (not base), so writes always carry the correct SHA.
Every API call (branch create, CHANGELOG.md, .version, PR) now retries 5× with HTTP code, curl exit code, and response body logged on failure.

Test plan

Trigger Release.yml on a repo with a pending changelog entry; confirm branch is created, both files written, and PR opened.
On transient errors, log shows HTTP code + curl rc + body on each retry.

## Why After #22 moved the branch-readiness poll before `.version` write, the workflow started failing **every run** with `exitcode '23'` and no error output. Exit 23 = `CURLE_WRITE_ERROR` from curl in the wait loop's `BRANCH_STATUS=$(curl ...)`. With `set -e`, any non-zero status from a command substitution aborts the script before the retry/echo path runs — so the failure was both deterministic and silent. ## Changes - Introduce an `api_call` helper that wraps curl with `|| rc=$?` and emits `<http_code>|<curl_rc>` plus the response body. Curl exit codes can no longer kill the script via `set -e`. - Create the `next-release` branch explicitly via `POST /branches` instead of relying on the `new_branch` parameter of the CHANGELOG.md PUT. Eliminates the race between branch creation and subsequent file writes. - Poll branch readiness after explicit creation. - Fetch file blob SHAs from `next-release` directly (not base), so writes always carry the correct SHA. - Every API call (branch create, CHANGELOG.md, .version, PR) now retries 5× with HTTP code, curl exit code, and response body logged on failure. ## Test plan - [ ] Trigger Release.yml on a repo with a pending changelog entry; confirm branch is created, both files written, and PR opened. - [ ] On transient errors, log shows HTTP code + curl rc + body on each retry.

argoyle added 1 commit 2026-05-13 10:53:02 +00:00

fix(release): make Release.yml robust to curl exit codes 9435cc506e

The previous fix moved the branch-readiness poll before the .version
write, but on at least one runner the poll's curl returned
CURLE_WRITE_ERROR (exit 23) immediately. With `set -e`, any non-zero
status from a command substitution (`VAR=$(curl ...)`) aborts the
script before the retry/echo path runs, so the failure was both
deterministic and silent.

Refactor the step around an `api_call` helper that wraps curl with
`|| rc=$?` and emits `<http_code>|<curl_rc>` plus body, so curl
exits never propagate through `set -e`.

Other changes:

- Create the `next-release` branch explicitly via `POST /branches`
  instead of relying on the `new_branch` parameter of the CHANGELOG.md
  PUT. Eliminates the race between branch creation and subsequent
  writes.
- Poll branch readiness after explicit creation.
- Fetch file blob SHAs from `next-release` directly (not base).
- Every write (CHANGELOG.md, .version, PR) retries 5x with HTTP code,
  curl exit code, and response body logged on failure.

argoyle merged commit 51b3b980a3 into main

2026-05-13 10:53:39 +00:00

argoyle deleted branch fix-release-curl-robustness

2026-05-13 10:53:40 +00:00

argoyle referenced this pull request

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

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

argoyle referenced this issue from a commit

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

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

Sign in to join this conversation.