Inside container: the act runner selects sh, not bash, and set -o pipefail is a bashism. homebrew-formula.yml carries the same set -euo pipefail 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. The fix is shell: bash, with that reasoning in a comment where the next person will hit 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 by running it, not by reading it
Against scratch issues, with the exact step script extracted from the YAML:
Case
Result
issue carries Status/In Progress
204, label gone, unclaim: #N is closed and unclaimed
issue never carried it
204, exit 0 — no failure
The second is what makes it safe on every close rather than only claimed ones. Both scratch issues were deleted afterwards.
I could not reproduce the dash failure locally — /bin/sh is a symlink to bash on this machine and dash is not installed — so the CI log is the evidence for the diagnosis rather than a local repro.
Still untested
Whether secrets.GITEA_TOKEN carries issue-write scope. The failing run never got far enough to find out, so that question is exactly as open as it was. If it 403s, the fix is one line: secrets.PACKAGE_TOKEN, which is a user PAT and definitely has it.
#102 is reopened rather than a new issue being filed — the feature shipped and does not work, so its "Done when" was never met. This PR's footer closes it again, and the merge is the test: #102 should end up closed and without Status/In Progress.
`unclaim.yml` shipped in #103 and **failed on every close**, on its second line, before reaching the API. Run `16961`, job `28107`:
```
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 `set -euo pipefail` 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. The fix is `shell: bash`, with that reasoning in a comment where the next person will hit 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 by running it, not by reading it
Against scratch issues, with the exact step script extracted from the YAML:
| Case | Result |
|---|---|
| issue carries `Status/In Progress` | `204`, label gone, `unclaim: #N is closed and unclaimed` |
| issue never carried it | `204`, exit 0 — no failure |
The second is what makes it safe on **every** close rather than only claimed ones. Both scratch issues were deleted afterwards.
I could not reproduce the dash failure locally — `/bin/sh` is a symlink to bash on this machine and dash is not installed — so the CI log is the evidence for the diagnosis rather than a local repro.
## Still untested
Whether `secrets.GITEA_TOKEN` carries issue-write scope. The failing run never got far enough to find out, so that question is exactly as open as it was. If it 403s, the fix is one line: `secrets.PACKAGE_TOKEN`, which is a user PAT and definitely has it.
**#102 is reopened** rather than a new issue being filed — the feature shipped and does not work, so its "Done when" was never met. This PR's footer closes it again, and the merge is the test: #102 should end up closed **and** without `Status/In Progress`.
Closes #102
yonlu
self-assigned this 2026-08-18 22:55:04 +00:00
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
yonlu
merged commit ad9c25a5a2 into main2026-08-18 23:05:38 +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.
unclaim.ymlshipped in #103 and failed on every close, on its second line, before reaching the API. Run16961, job28107:Inside
container:the act runner selectssh, not bash, andset -o pipefailis a bashism.homebrew-formula.ymlcarries the sameset -euo pipefailwithout 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. The fix isshell: bash, with that reasoning in a comment where the next person will hit it.pipefailis kept rather than dropped for POSIX's sake. The lookup iscurl -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 by running it, not by reading it
Against scratch issues, with the exact step script extracted from the YAML:
Status/In Progress204, label gone,unclaim: #N is closed and unclaimed204, exit 0 — no failureThe second is what makes it safe on every close rather than only claimed ones. Both scratch issues were deleted afterwards.
I could not reproduce the dash failure locally —
/bin/shis a symlink to bash on this machine and dash is not installed — so the CI log is the evidence for the diagnosis rather than a local repro.Still untested
Whether
secrets.GITEA_TOKENcarries issue-write scope. The failing run never got far enough to find out, so that question is exactly as open as it was. If it 403s, the fix is one line:secrets.PACKAGE_TOKEN, which is a user PAT and definitely has it.#102 is reopened rather than a new issue being filed — the feature shipped and does not work, so its "Done when" was never met. This PR's footer closes it again, and the merge is the test: #102 should end up closed and without
Status/In Progress.Closes #102