release/0.2 lacks the test-release-ci fix, so a 0.2.6.7 release build would fail its own checks #2

Open
opened 2026-10-14 04:30:39 +00:00 by ekklesia-bot · 0 comments
Member

Summary

tests/test-release-ci.sh on release/0.2 fails whenever it runs under Gitea Actions: 26 passed, 13 failed. The fix (0bc8851, then 719c0f7) landed on master only. release/0.2 is 0 commits ahead of and 2 behind master, the two missing commits being exactly that fix.

Release 1 - build runs tools/check.sh (which includes this test) before building, and maintenance releases are built from release/0.2. So the next maintenance release, 0.2.6.7 (the documented path if 0.2.6.6's physical checks fail), would be refused by its own release build under Actions.

Cause

The test exports a stand-in Gitea and server, but before the fix it only unset GITHUB_RUN_NUMBER GITHUB_REF GITHUB_OUTPUT RELEASE_SSH_KEY. Under Actions, GITHUB_ACTIONS / GITEA_ACTIONS stay set, so tools/release-ci.sh and tools/gitea-release take their "running in Actions" paths against the stand-ins. Those include the ssh -F key handling and the release-record reads, and they fail. The fix is one line (719c0f7):

-unset GITHUB_RUN_NUMBER GITHUB_REF GITHUB_OUTPUT RELEASE_SSH_KEY
+unset GITHUB_ACTIONS GITEA_ACTIONS GITHUB_RUN_NUMBER GITHUB_REF GITHUB_OUTPUT RELEASE_SSH_KEY

Evidence

  • CI run #1 (14291fd, the commit release/0.2 still points at) and run #3 (0bc8851): test-release-ci FAIL, 26 passed, 13 failed, for example FAIL the record has the promotion and its approval, FAIL the record reads in order: created, Preview, Stable (ValueError: substring not found), FAIL no channel serves it now, so the record claims neither.
  • Run #4 (719c0f7): checks passes, 31/31.
  • Reproduced locally with an Actions-like environment (GITHUB_ACTIONS=true GITEA_ACTIONS=true GITHUB_SERVER_URL=… GITHUB_REPOSITORY=… GITHUB_REF=…):
    • origin/release/0.2: exit 1, 26 passed, 13 failed
    • origin/master: exit 0, 39 passed, 0 failed
  • Without those variables, tools/check.sh passes on both, which is why it works by hand and fails in CI.

Suggested fix

Apply the one-line change to release/0.2 in its own pull request. docs/releasing.md says fixes are made on the maintenance branch and merged forward; this one went the other way, so the PR should say so. After it merges, release/0.2 and master share the identical line again, and a later git merge release/0.2 into master is a no-op for this file.

Not checked

Whether any other master-only commit is also needed for a release build on release/0.2. git log origin/release/0.2..origin/master currently lists only these two.


Found by Claude during a review of Classroom_Desktop's CI, 2026-10-14 (found-by-claude).

## Summary `tests/test-release-ci.sh` on `release/0.2` fails whenever it runs under Gitea Actions: **26 passed, 13 failed**. The fix (`0bc8851`, then `719c0f7`) landed on `master` only. `release/0.2` is 0 commits ahead of and 2 behind `master`, the two missing commits being exactly that fix. **Release 1 - build** runs `tools/check.sh` (which includes this test) before building, and maintenance releases are built from `release/0.2`. So the next maintenance release, 0.2.6.7 (the documented path if 0.2.6.6's physical checks fail), would be refused by its own release build under Actions. ## Cause The test exports a stand-in Gitea and server, but before the fix it only unset `GITHUB_RUN_NUMBER GITHUB_REF GITHUB_OUTPUT RELEASE_SSH_KEY`. Under Actions, `GITHUB_ACTIONS` / `GITEA_ACTIONS` stay set, so `tools/release-ci.sh` and `tools/gitea-release` take their "running in Actions" paths against the stand-ins. Those include the `ssh -F` key handling and the release-record reads, and they fail. The fix is one line (`719c0f7`): ```diff -unset GITHUB_RUN_NUMBER GITHUB_REF GITHUB_OUTPUT RELEASE_SSH_KEY +unset GITHUB_ACTIONS GITEA_ACTIONS GITHUB_RUN_NUMBER GITHUB_REF GITHUB_OUTPUT RELEASE_SSH_KEY ``` ## Evidence - CI [run #1](https://git.zayin.net/Zayin/Classroom_Desktop/actions/runs/89) (`14291fd`, the commit `release/0.2` still points at) and [run #3](https://git.zayin.net/Zayin/Classroom_Desktop/actions/runs/95) (`0bc8851`): `test-release-ci` FAIL, `26 passed, 13 failed`, for example `FAIL the record has the promotion and its approval`, `FAIL the record reads in order: created, Preview, Stable` (`ValueError: substring not found`), `FAIL no channel serves it now, so the record claims neither`. - [Run #4](https://git.zayin.net/Zayin/Classroom_Desktop/actions/runs/96) (`719c0f7`): `checks` passes, 31/31. - Reproduced locally with an Actions-like environment (`GITHUB_ACTIONS=true GITEA_ACTIONS=true GITHUB_SERVER_URL=… GITHUB_REPOSITORY=… GITHUB_REF=…`): - `origin/release/0.2`: exit 1, `26 passed, 13 failed` - `origin/master`: exit 0, `39 passed, 0 failed` - Without those variables, `tools/check.sh` passes on both, which is why it works by hand and fails in CI. ## Suggested fix Apply the one-line change to `release/0.2` in its own pull request. `docs/releasing.md` says fixes are made on the maintenance branch and merged *forward*; this one went the other way, so the PR should say so. After it merges, `release/0.2` and `master` share the identical line again, and a later `git merge release/0.2` into `master` is a no-op for this file. ## Not checked Whether any other `master`-only commit is also needed for a release build on `release/0.2`. `git log origin/release/0.2..origin/master` currently lists only these two. --- _Found by Claude during a review of Classroom_Desktop's CI, 2026-10-14 (`found-by-claude`)._
ekklesia-bot added the found-by-claude label 2026-10-14 04:40:48 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Zayin/Classroom_Desktop#2