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):
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.
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`)._
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.
Summary
tests/test-release-ci.shonrelease/0.2fails whenever it runs under Gitea Actions: 26 passed, 13 failed. The fix (0bc8851, then719c0f7) landed onmasteronly.release/0.2is 0 commits ahead of and 2 behindmaster, 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 fromrelease/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_ACTIONSstay set, sotools/release-ci.shandtools/gitea-releasetake their "running in Actions" paths against the stand-ins. Those include thessh -Fkey handling and the release-record reads, and they fail. The fix is one line (719c0f7):Evidence
14291fd, the commitrelease/0.2still points at) and run #3 (0bc8851):test-release-ciFAIL,26 passed, 13 failed, for exampleFAIL 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.719c0f7):checkspasses, 31/31.GITHUB_ACTIONS=true GITEA_ACTIONS=true GITHUB_SERVER_URL=… GITHUB_REPOSITORY=… GITHUB_REF=…):origin/release/0.2: exit 1,26 passed, 13 failedorigin/master: exit 0,39 passed, 0 failedtools/check.shpasses on both, which is why it works by hand and fails in CI.Suggested fix
Apply the one-line change to
release/0.2in its own pull request.docs/releasing.mdsays 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.2andmastershare the identical line again, and a latergit merge release/0.2intomasteris a no-op for this file.Not checked
Whether any other
master-only commit is also needed for a release build onrelease/0.2.git log origin/release/0.2..origin/mastercurrently lists only these two.Found by Claude during a review of Classroom_Desktop's CI, 2026-10-14 (
found-by-claude).