Second defect in unclaim.yml. The shell: bash fix from #108 took — the step ran under bash --noprofile --norc -e -o pipefail — and got one layer further before failing. Run 16971, job 28120:
ubuntu:24.04 ships no CA bundle, and --no-install-recommends skips the ca-certificates that curl recommends. So curl came up unable to verify TLS against our own Gitea.
This was avoidable by reading the repo rather than reasoning about it.ci.yml (twice), desktop-assets.yml, android-apk.yml and release.yml all spell out ca-certificates curl … jq for exactly this reason. The convention was already written down five times.
Validated in the real image this time
Extracting the script and running it on the host is what missed this — the host has a CA bundle. So both directions were checked inside docker run ubuntu:24.04, the same image the runner uses:
Result
this version, scratch issue carrying the label
204, label gone, step succeeds
previous version (no ca-certificates)
curl: (77) — the CI failure, reproduced
Scratch issue deleted afterwards.
One more change
The DELETE keeps its response body and prints it on a non-204. Whether secrets.GITEA_TOKEN carries issue-write scope is still unproven — both failures happened before the API call — and 403 without Gitea's own sentence would cost another merge to interpret. Now the log says which it is.
Where this leaves the feature
The footer half is confirmed and working (#100, #102 both closed themselves). Only the unclaim half has been broken, twice, and both were my mistakes in the container bootstrap rather than anything about the design.
#102 is reopened for the third time rather than a fresh issue: the feature shipped and does not work, so its "Done when" is still unmet, and the comment history is the honest record of what it took. The merge is the test again — #102 should end up closed and without Status/In Progress.
Second defect in `unclaim.yml`. The `shell: bash` fix from #108 took — the step ran under `bash --noprofile --norc -e -o pipefail` — and got one layer further before failing. Run `16971`, job `28120`:
```
curl: (77) error setting certificate file: /etc/ssl/certs/ca-certificates.crt
```
`ubuntu:24.04` ships no CA bundle, and `--no-install-recommends` skips the `ca-certificates` that curl recommends. So curl came up unable to verify TLS against our own Gitea.
**This was avoidable by reading the repo rather than reasoning about it.** `ci.yml` (twice), `desktop-assets.yml`, `android-apk.yml` and `release.yml` all spell out `ca-certificates curl … jq` for exactly this reason. The convention was already written down five times.
## Validated in the real image this time
Extracting the script and running it on the host is what missed this — the host has a CA bundle. So both directions were checked inside `docker run ubuntu:24.04`, the same image the runner uses:
| | Result |
|---|---|
| this version, scratch issue carrying the label | `204`, label gone, step succeeds |
| previous version (no `ca-certificates`) | `curl: (77)` — the CI failure, reproduced |
Scratch issue deleted afterwards.
## One more change
The `DELETE` keeps its response body and prints it on a non-204. Whether `secrets.GITEA_TOKEN` carries issue-write scope is **still unproven** — both failures happened before the API call — and `403` without Gitea's own sentence would cost another merge to interpret. Now the log says which it is.
## Where this leaves the feature
The footer half is confirmed and working (#100, #102 both closed themselves). Only the unclaim half has been broken, twice, and both were my mistakes in the container bootstrap rather than anything about the design.
**#102 is reopened for the third time** rather than a fresh issue: the feature shipped and does not work, so its "Done when" is still unmet, and the comment history is the honest record of what it took. The merge is the test again — #102 should end up closed **and** without `Status/In Progress`.
Closes #102
yonlu
self-assigned this 2026-08-18 23:09:15 +00:00
Second defect in the same workflow. The shell fix took -- the step ran
under `bash --noprofile --norc -e -o pipefail` -- and got one layer
further before failing:
curl: (77) error setting certificate file: /etc/ssl/certs/ca-certificates.crt
ubuntu:24.04 ships no CA bundle, and --no-install-recommends skips the
ca-certificates that curl recommends, so curl came up unable to verify
TLS against our own Gitea.
This was avoidable by reading the repo rather than reasoning about it:
ci.yml (twice), desktop-assets.yml, android-apk.yml and release.yml all
spell out `ca-certificates curl ... jq` for exactly this reason. The
convention was written down five times already.
Validated in the real image this time rather than by extracting the
script and running it on the host, which is what missed this: the step
now succeeds inside `docker run ubuntu:24.04` against a scratch issue --
label present, 204, label gone -- and the previous version reproduces
`curl: (77)` in the same image. Both checked, then the scratch issue was
deleted.
The DELETE also keeps its response body now and prints it on a non-204.
Whether the automatic token carries issue-write scope is still unproven,
because both failures happened before the API call, and "403" without
Gitea's own sentence would cost another merge to interpret.
Closes#102
yonlu
merged commit bf0a53e64c into main2026-08-18 23:30:31 +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.
Second defect in
unclaim.yml. Theshell: bashfix from #108 took — the step ran underbash --noprofile --norc -e -o pipefail— and got one layer further before failing. Run16971, job28120:ubuntu:24.04ships no CA bundle, and--no-install-recommendsskips theca-certificatesthat curl recommends. So curl came up unable to verify TLS against our own Gitea.This was avoidable by reading the repo rather than reasoning about it.
ci.yml(twice),desktop-assets.yml,android-apk.ymlandrelease.ymlall spell outca-certificates curl … jqfor exactly this reason. The convention was already written down five times.Validated in the real image this time
Extracting the script and running it on the host is what missed this — the host has a CA bundle. So both directions were checked inside
docker run ubuntu:24.04, the same image the runner uses:204, label gone, step succeedsca-certificates)curl: (77)— the CI failure, reproducedScratch issue deleted afterwards.
One more change
The
DELETEkeeps its response body and prints it on a non-204. Whethersecrets.GITEA_TOKENcarries issue-write scope is still unproven — both failures happened before the API call — and403without Gitea's own sentence would cost another merge to interpret. Now the log says which it is.Where this leaves the feature
The footer half is confirmed and working (#100, #102 both closed themselves). Only the unclaim half has been broken, twice, and both were my mistakes in the container bootstrap rather than anything about the design.
#102 is reopened for the third time rather than a fresh issue: the feature shipped and does not work, so its "Done when" is still unmet, and the comment history is the honest record of what it took. The merge is the test again — #102 should end up closed and without
Status/In Progress.Closes #102