yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Drop Status/In Progress automatically when an issue closes #102

New Issue
Closed
opened 2026-08-18 21:35:00 +00:00 by yonlu · 5 comments
yonlu commented 2026-08-18 21:35:00 +00:00
Owner
Copy Link
Copy Source

A Closes #N footer closes the issue on merge and leaves Status/In Progress on it — so #100 was simultaneously closed and marked as being actively worked on. scripts/issue.sh close drops the label, but the whole point of the footer is that nobody calls close.

Left alone this accumulates silently, which is the same shape as #83: a mechanism that half-works, and nobody notices for a fortnight.

Hook the close, not the merge

The obvious fix is "strip the label before merging", but that is a per-PR habit and habits are what this is trying to remove. on: issues: [closed] covers every path an issue can close by — the footer on merge, issue.sh close, someone clicking Close in the UI — and needs no thought at any of them.

Gitea is 1.27.2, so the issues event is available to Actions.

Shape

An eighth workflow, .gitea/workflows/unclaim.yml, on issues: types: [closed]: look the label id up by name, DELETE it from the issue, exit 0 when it is not there. It authenticates with the automatic secrets.GITEA_TOKEN, which release.yml already uses for the floor tag.

Two honest costs:

  • The runner has capacity 1 and is shared with an index build that can hold it for three hours. A label tweak can therefore sit in the queue behind one. The label being stale for a few hours is a great deal better than being stale forever, but it is not instant and should not be described as such.
  • It is an eighth workflow, and CLAUDE.md's CI section counts them. That count has to move with it.

Reopening deliberately does not restore the label. Reopening an issue says the work was not finished, not that somebody is at a keyboard doing it now — the claim should be re-made explicitly by whoever picks it up.

The fallback stays

./scripts/issue.sh list --state closed --label "Status/In Progress" is the audit that answers "did this actually work", and it stays in CLAUDE.md. A workflow that silently stops firing is exactly the failure this whole thread has been about.

Done when

An issue closed by a Closes footer ends up closed and unclaimed, with nobody having touched the label.

A `Closes #N` footer closes the issue on merge and **leaves `Status/In Progress` on it** — so #100 was simultaneously closed and marked as being actively worked on. `scripts/issue.sh close` drops the label, but the whole point of the footer is that nobody calls `close`. Left alone this accumulates silently, which is the same shape as #83: a mechanism that half-works, and nobody notices for a fortnight. ## Hook the close, not the merge The obvious fix is "strip the label before merging", but that is a per-PR habit and habits are what this is trying to remove. `on: issues: [closed]` covers **every** path an issue can close by — the footer on merge, `issue.sh close`, someone clicking Close in the UI — and needs no thought at any of them. Gitea is 1.27.2, so the `issues` event is available to Actions. ## Shape An eighth workflow, `.gitea/workflows/unclaim.yml`, on `issues: types: [closed]`: look the label id up by name, `DELETE` it from the issue, exit 0 when it is not there. It authenticates with the automatic `secrets.GITEA_TOKEN`, which `release.yml` already uses for the floor tag. Two honest costs: - **The runner has capacity 1** and is shared with an index build that can hold it for three hours. A label tweak can therefore sit in the queue behind one. The label being stale for a few hours is a great deal better than being stale forever, but it is not instant and should not be described as such. - **It is an eighth workflow**, and CLAUDE.md's CI section counts them. That count has to move with it. **Reopening deliberately does not restore the label.** Reopening an issue says the work was not finished, not that somebody is at a keyboard doing it now — the claim should be re-made explicitly by whoever picks it up. ## The fallback stays `./scripts/issue.sh list --state closed --label "Status/In Progress"` is the audit that answers "did this actually work", and it stays in CLAUDE.md. A workflow that silently stops firing is exactly the failure this whole thread has been about. ## Done when An issue closed by a `Closes` footer ends up closed and unclaimed, with nobody having touched the label.
yonlu added the
Priority
Medium
3
Kind/Enhancement labels 2026-08-18 21:35:00 +00:00
yonlu self-assigned this 2026-08-18 21:36:04 +00:00
yonlu added the
Status
In Progress
 label 2026-08-18 21:36:05 +00:00
yonlu commented 2026-08-18 21:36:05 +00:00
Author
Owner
Copy Link
Copy Source

Starting work on this on ci/unclaim-on-close.

Starting work on this on `ci/unclaim-on-close`.
yonlu closed this issue 2026-08-18 21:57:11 +00:00
yonlu reopened this issue 2026-08-18 22:53:22 +00:00
yonlu commented 2026-08-18 22:53:23 +00:00
Author
Owner
Copy Link
Copy Source

Reopening: the workflow shipped in #103 and fails on every close. Run 16961, job 28107:

shell: sh -e {0}
/var/run/act/workflow/0.sh: 2: set: Illegal option -o pipefail

The step never reached the API — so this says nothing about whether secrets.GITEA_TOKEN has issue-write scope, which is still the untested part.

My bug, and the trap is worth writing down: inside container: ubuntu:24.04 the act runner selects sh, not bash, and set -o pipefail is a bashism. homebrew-formula.yml uses the same line without trouble because it runs with no container, on the host image where bash is the default. So "the other workflow does it" was not the evidence it looked like.

The footer half worked correctly: this issue was closed at 21:57:11 by Closes #102. Only the unclaim half is broken, which is exactly why it still wears Status/In Progress.

Reopening: the workflow shipped in #103 and **fails on every close**. Run `16961`, job `28107`: ``` shell: sh -e {0} /var/run/act/workflow/0.sh: 2: set: Illegal option -o pipefail ``` The step never reached the API — so this says nothing about whether `secrets.GITEA_TOKEN` has issue-write scope, which is still the untested part. My bug, and the trap is worth writing down: inside `container: ubuntu:24.04` the act runner selects **`sh`**, not bash, and `set -o pipefail` is a bashism. `homebrew-formula.yml` uses the same line without trouble because it runs with **no container**, on the host image where bash is the default. So "the other workflow does it" was not the evidence it looked like. The footer half worked correctly: this issue was closed at `21:57:11` by `Closes #102`. Only the unclaim half is broken, which is exactly why it still wears `Status/In Progress`.
yonlu commented 2026-08-18 22:53:25 +00:00
Author
Owner
Copy Link
Copy Source

Starting work on this on fix/unclaim-shell.

Starting work on this on `fix/unclaim-shell`.
yonlu closed this issue 2026-08-18 23:05:38 +00:00
yonlu reopened this issue 2026-08-18 23:07:31 +00:00
yonlu commented 2026-08-18 23:07:31 +00:00
Author
Owner
Copy Link
Copy Source

Reopening again — second defect in the same shipped workflow. The shell: bash fix took (shell: bash --noprofile --norc -e -o pipefail {0}), and the step 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 I installed curl with --no-install-recommends, which skips the ca-certificates it recommends. So curl came up unable to verify TLS against our own Gitea.

This one was avoidable by reading the repo rather than reasoning. Every other containerised workflow here — ci.yml (twice), desktop-assets.yml, android-apk.yml, release.yml — spells out ca-certificates curl … jq for exactly this reason. The convention was already written down five times and I did not follow it.

The token-scope question is still untested, since this failed before the API call again. The fix now prints the response body on a non-204 so a 403 is diagnosable from the log rather than costing another round trip.

Reopening again — second defect in the same shipped workflow. The `shell: bash` fix took (`shell: bash --noprofile --norc -e -o pipefail {0}`), and the step 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 I installed curl with `--no-install-recommends`, which skips the `ca-certificates` it recommends. So curl came up unable to verify TLS against our own Gitea. **This one was avoidable by reading the repo rather than reasoning.** Every other containerised workflow here — `ci.yml` (twice), `desktop-assets.yml`, `android-apk.yml`, `release.yml` — spells out `ca-certificates curl … jq` for exactly this reason. The convention was already written down five times and I did not follow it. The token-scope question is *still* untested, since this failed before the API call again. The fix now prints the response body on a non-204 so a 403 is diagnosable from the log rather than costing another round trip.
yonlu commented 2026-08-18 23:07:34 +00:00
Author
Owner
Copy Link
Copy Source

Starting work on this on fix/unclaim-ca-certs.

Starting work on this on `fix/unclaim-ca-certs`.
yonlu closed this issue 2026-08-18 23:30:32 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-18 23:30:43 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Kind/Enhancement
Priority
Medium
3
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees yonlu
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#102