stack-close: wait for CI via the authenticated Gitea connection, with timings and a give-up point
CI / verify (push) Successful in 1m11s
Release / release (push) Successful in 37s

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/stack-close/SKILL.md
This commit is contained in:
torben committed 2026-09-25 21:00:43 +02:00
1 parent 6d53c55d0d
commit 919e733e21
3 files changed
+30 -2

No files matched your search

+12 -1
View File
@@ -59,7 +59,7 @@ concern - readable here, never shipped as something to parse.
---
## 7.1.0-beta.2 - 2026-09-25 - version bump no longer points at version release in its output
## 7.1.0-beta.3 - 2026-09-25 - stack-close: wait for CI through the authenticated Gitea connection, with timings and a give-up point
**Author:** Torben Nehmer
@@ -69,6 +69,7 @@ concern - readable here, never shipped as something to parse.
**Low impact**
- version bump no longer points at version release in its output
- stack-close: wait for CI through the authenticated Gitea connection, with timings and a give-up point
<!-- /wikitool:bumps -->
### CalDAV task-tracker provider (Nextcloud Tasks, iOS Reminders); review reports unknown-value findings instead of skipping them
@@ -100,6 +101,16 @@ an agent read that as its own next step and fixed a candidate into a release una
is gone: whether a candidate ships is the user's decision, as `DEVELOPMENT.md` already says for
humans, and `instructions/dev/version-parts.md` step 7 now says so for agents.
### stack-close: wait for CI through the authenticated Gitea connection, with timings and a give-up point
Sessions kept improvising how to wait for CI before closing an issue, and one of those
improvisations - an anonymous `curl` loop against the Actions API, which answers `401` even for
this public repo - treated every error as "not finished yet" and never ended. `stack-close` step 2
now names the one way to do it: read the runs through the authenticated Gitea connection, first
check after about 4 minutes (5 with a release job), then once a minute, and hand back to the user
after 15. Any shell loop that polls instead must end on the first unexpected response. Dev-only;
nothing here ships to an instance.
---
## 7.0.0 - 2026-09-22 - Task-Tracker-Anbindung: Vorhaben als Seitenart, Verpflichtungsschicht, Weekly Review als Read-Time-Join
+1 -1
View File
@@ -1 +1 @@
7.1.0-beta.2
7.1.0-beta.3
+17
View File
@@ -71,6 +71,23 @@ and a fresh subagent starts without the session's context).
`instructions/dev/issue-tracking.md` steps 2-3 and 7 have the full shape; this is that
procedure, run at the point this skill exists to guarantee it actually gets run.
**Close only once CI on the published commit is green, and wait for it this way.** The
push-triggered runs take about **4 minutes**; a push that moved `VERSION` to a suffix-free
release adds about **1 minute** for the release job. So:
- Read the runs for the published commit's SHA through the authenticated Gitea connection
`ENVIRONMENT.md` lists (the Gitea MCP's `actions_run_read`, `list_runs`), right after
`publish`, to get their ids. **Never anonymously via `curl`:** Gitea answers the Actions
API with `401 token is required` even for this public repo.
- Check again after about 4 minutes (5 with a release job), then once a minute.
- **Give up after 15 minutes** and hand the open runs to the user by id and link, rather than
waiting on.
- Any shell loop that polls instead must **end on the first non-2xx status or missing field**
and print the raw response. A loop that treats an error as "not finished yet" never ends;
that happened in the #139 close-out.
A red run is not closed over: report it, and the package stays open until it is fixed.
**A closing report in a comment does not satisfy this**, however thorough: it reads as
complete to whoever writes it and leaves a body still phrased as open work. Nothing mechanical
catches it, which is why this is a step - and now a whole skill - rather than a habit. #44 and