instructions/dev: publish-and-ci - CI-Wartezeiten auf gemessene Laufzeiten (ein Runner, Jobs nacheinander, ca. 12 Min; Konverter ca. 22), Aufgeben nach 25/35 statt 15 Min; stack-build verweist auf die Grenze statt sie zu wiederholen; 10.1.0-beta.18
CI / verify (push) Successful in 7m48s
CI / pwsh (push) Successful in 2m52s
Release / converters (push) Successful in 27s
Release / release (push) Successful in 36s
Release / wiki-mirror (push) Skipped

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/publish-and-ci.md
- instructions/dev/stack-build/SKILL.md

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2
This commit is contained in:
torbenandClaude Opus 5.5 committed 2026-10-16 12:12:36 +02:00
1 parent 77fb427efd
commit 7bb983d855
4 files changed
+18 -12

No files matched your search

+14 -9
View File
@@ -38,17 +38,21 @@ formality after it - which is why waiting for it belongs to the phase that wrote
**CI does the tagging** - a session never creates a tag, which is what keeps AGENTS.md
invariant 5 intact.
3. **Wait for CI on the published commit, 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.
3. **Wait for CI on the published commit, this way.** One runner serves the repository, so the
jobs of a push run **one after another**, never side by side: CI's `verify` job (about
**8 minutes**) and `pwsh` job (about **3 minutes**) first, then the second run a push to
`main` starts - `release.yml`, preceded by the `Converters` check - which waits `queued`
until CI is done and then takes about **1 minute**. From the push to the last green run that
is about **12 minutes** (measured 10.5 to 13 minutes, October 2026); a second run still
`queued` while CI works is the runner's order, not a hang.
- 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.
- Check again after about 11 minutes, then every 2 minutes.
- **Give up after 25 minutes** - twice the usual time, so a slow day is not mistaken for a
hang - 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.
@@ -59,9 +63,10 @@ formality after it - which is why waiting for it belongs to the phase that wrote
surface - `tools/chemenu/filters/`, `tools/chemenu/commands/raw/derive.py` or `accept.py`,
`tools/chemenu/tests/test_raw_derive*.py`, `tools/chemenu/tests/binary_formats.py`,
`tools/requirements.txt` or `.gitea/workflows/converters.yml` - the `Converters` workflow
(`converters.yml`) starts by itself beside CI and derives the real documents of the private
test corpus. It takes longer than CI (allow **10 minutes**); wait for it the same way, with
the same give-up time, and count a red run like a red CI run (step 4). Start it by hand
(`converters.yml`) starts by itself with CI and derives the real documents of the private
test corpus. Deriving the corpus takes about **10 minutes** on top of CI, on the same
runner and after it, so the last run finishes about **22 minutes** after the push; give up
after **35 minutes** instead of 25, and count a red run like a red CI run (step 4). Start it by hand
(`actions_run_write`, `dispatch_workflow` on `main`) when only the private repository changed
or when the commit reaches the converters only indirectly. A release without suffix runs the
same steps as the first job of `release.yml`, which the release waits for.
+1 -1
View File
@@ -112,7 +112,7 @@ session, or a fresh one after `/clear` - assume the second, and work from the bo
answer as a design change (step 3's first fixed point).
- **The package needs several build sessions?** Each one ends with the body current and its own
changelog comment; the phase ends once, at the green run after the last publish.
- **CI gave up after 15 minutes, or is red for a reason outside this change?** Hand the open or
- **CI hit the give-up time in `instructions/dev/publish-and-ci.md` step 3, or is red for a reason outside this change?** Hand the open or
failing runs to the operator by id and link. The phase is not over, and the closing line in
step 7 is not given.