3 Commits

Include renames

Author	SHA1	Message	Date
yonlu	7be4a02e31	fix(ci): give the unclaim step a CA bundle ... 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	2026-08-18 19:08:50 -04:00
yonlu	a83a127e31	fix(ci): run the unclaim step under bash ... The workflow shipped in #103 and failed on every close, on its second line, before reaching the API: shell: sh -e {0} /var/run/act/workflow/0.sh: 2: set: Illegal option -o pipefail Inside `container:` the act runner selects sh, not bash, and `set -o pipefail` is a bashism. homebrew-formula.yml carries the same line without trouble because it runs with no container, on the host image where bash is the default -- so "another workflow does it" was not the evidence it looked like, and the comment now says so where the next person will read it. pipefail is kept rather than dropped for POSIX's sake: the lookup is `curl -sSf ... | jq`, so without it an API error yields empty output, an empty label id, and a cheerful "nothing to do" on every close. A silent no-op is the one outcome worse than a failing job here. Validated end to end against scratch issues rather than by reading it: with the label present the step returns 204 and the label is gone, and against an issue that never carried it the step also returns 204 and exits 0 -- which is what makes it safe to run on every close rather than only claimed ones. Still untested: whether secrets.GITEA_TOKEN carries issue-write scope. The old run never got far enough to find out. If it 403s, the fix is one line -- secrets.PACKAGE_TOKEN, which is a user PAT. Closes #102	2026-08-18 18:54:39 -04:00
yonlu	0c944f2382	ci: drop the claim label when an issue closes ... A `Closes #N` footer closes the issue on merge and leaves `Status/In Progress` on it, because Gitea's auto-close touches state and nothing else. #100 was closed and simultaneously marked as being actively worked on. `scripts/issue.sh close` does drop the label, and is exactly the call the footer exists to avoid making. This hooks the close rather than the merge. Stripping the label in the PR would work and would be a per-PR habit, which is what the footer removed in the first place; `issues: [closed]` covers the footer, issue.sh close and a click in the web UI alike, and asks nothing of anyone at any of them. Reopening deliberately does not restore the label: reopening says the work was not finished, not that somebody is at a keyboard now. Two costs, both stated in the file rather than discovered later. The runner has capacity 1 and is shared with an index build that can hold it for three hours, so this is not instant -- stale for an afternoon beats stale forever, which is what it was. And it is an eighth workflow, so CLAUDE.md's count moves with it. The audit stays, because a workflow that silently stops firing is the failure mode this area has already produced once: ./scripts/issue.sh list --state closed --label "Status/In Progress" Closes #102	2026-08-18 17:36:05 -04:00