recipe-maintainers/cc-ci-orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

skills: PR-merge policy + test-before-switch + new /cc-ci-orchestrator-update

Browse Source 
- cc-ci-server-update / cc-ci-tests-update / cc-ci-update: operator policy change —
  open PRs for visibility/historical record and merge directly once verified
  (invocation = authorization); reports must list merged-PR links + change summaries.
  (tests-update still never merges the paired recipe upgrade PRs.)
- cc-ci-server-update: mandatory nixos-rebuild test step (5d) before switch, with
  detached-activation + transient-unit notes from the 2026-08-03 26.05 deploy.
- AGENTS.md: test-before-switch policy for orchestrator host rebuilds.
- NEW skill cc-ci-orchestrator-update (+ thin .claude wrapper): the /cc-ci-server-update
  analogue for this host (flake /srv/cc-ci-orch, .#cc-ci-orchestrator-hetzner, Hetzner
  server 134487234), with self-update caveats.
- JOURNAL.md: 2026-08-03 server-update incident/recovery handoff entry.
This commit is contained in:
autonomic-bot
2026-08-03 20:35:51 +00:00
parent 2f22d42d34
commit d95afd934b
10 changed files with 282 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.opencode/skills/cc-ci-tests-update/SKILL.md
+25 -18
View File
@@ -1,6 +1,6 @@
---
name: cc-ci-tests-update
description: Sweep all maintained recipes for stale cc-ci tests and update the stale ones so they pass again, verified via the standard PR + !testme -> CI flow. Runs the deterministic test suite across every enrolled recipe, identifies failures caused by a genuinely-stale test (the recipe legitimately changed upstream and the cc-ci test/overlay still asserts the old behavior), authors the minimal test update, opens a cc-ci test PR per stale recipe, and verifies each by running !testme on the corresponding recipe upgrade PR with the test change applied (or a direct harness run with the cc-ci branch checked out). NEVER weakens a test to force green; never merges. The fleet-wide stale-test cleanup that the weekly /upgrade-all deliberately defers (it comments-only on stale tests; this skill closes the loop). Invoke as /cc-ci-tests-update.
description: Sweep all maintained recipes for stale cc-ci tests and update the stale ones so they pass again, verified via the standard PR + !testme -> CI flow. Runs the deterministic test suite across every enrolled recipe, identifies failures caused by a genuinely-stale test (the recipe legitimately changed upstream and the cc-ci test/overlay still asserts the old behavior), authors the minimal test update, opens a cc-ci test PR per stale recipe, and verifies each by running !testme on the corresponding recipe upgrade PR with the test change applied (or a direct harness run with the cc-ci branch checked out). NEVER weakens a test to force green. Opens each cc-ci test PR for visibility/historical record and merges it directly once verified green (the skill invocation IS the authorization); the end-of-run report includes every merged PR link + a summary of what changed. The fleet-wide stale-test cleanup that the weekly /upgrade-all deliberately defers (it comments-only on stale tests; this skill closes the loop). Invoke as /cc-ci-tests-update.
---
# cc-ci-tests-update
@@ -12,7 +12,8 @@ PR and stops (operator decides). Over time those commented stale tests accumulat
**closes that loop**: it sweeps every maintained recipe, finds the ones whose cc-ci test is stale,
authors the minimal test update, opens a cc-ci test PR per stale recipe, and **verifies** each via
the standard `!testme` → CI flow (or a direct harness run with the test branch applied). It never
weakens a test and never merges.
weakens a test. Verified test PRs are merged directly — the PR is the visible, reviewable record;
the invocation is the authorization — and the report lists every merged PR + what changed.
> **Relationship to the other skills.** This is the fleet-wide version of the per-recipe
> `--with-tests` path in `/recipe-upgrade` (step 5b), and the "TEST out-of-date" classification
@@ -29,7 +30,10 @@ weakens a test and never merges.
- **Does NOT fix real upgrade regressions** — if a recipe's `!testme` is red because the upgrade is
broken (not because the test is stale), that's a `/recipe-upgrade` (step 5a) or `/ci-test-review`
job. This skill only touches a test when the **upgrade is correct** and the **test is wrong**.
- **Does NOT merge** any PR — operator merges after review.
- **Does merge its own cc-ci test PRs** (once verified green) — they're opened for visibility and
historical record; the invocation is the authorization, and the operator reviews the merged PRs
via the links in the report. It does NOT merge the paired **recipe upgrade PRs** — those stay
operator-owned (`/upgrade-all` scope).
## Preconditions / access
@@ -125,7 +129,7 @@ ruff check tests/<recipe>/ && ruff format --check tests/<recipe>/
```
Fix any lint errors you introduce (don't commit red lint).
### 3. Open the cc-ci test PR (never merge)
### 3. Open the cc-ci test PR (merged in step 4 once verified)
```
git add tests/<recipe>/
@@ -145,8 +149,9 @@ BODY_FILE=/tmp/cc-ci-tests-<recipe>-pr-body.md \
bash /srv/cc-ci-orch/.claude/skills/ci-test-review/open-cc-ci-pr.sh
```
The PR body must: name the stale test, explain what changed upstream, state that no assertion was
weakened, link the **dependent recipe upgrade PR** (the test change only goes green once the recipe
upgrade is also applied — they're a pair), and say "NOT merged — for operator review."
weakened, and link the **dependent recipe upgrade PR** (the test change only goes green once the
recipe upgrade is also applied — they're a pair). The PR is opened for visibility and historical
record; it gets merged directly once verification is green (step 4).
Capture the `TEST_PR_URL`.
@@ -189,11 +194,11 @@ ssh cc-ci 'rm -rf /root/cc-ci-test-verify'
re-verify. If still red after 3, leave the test PR open and report `FAILED — test update not green
after 3 verify runs` with the failing evidence. Don't weaken the test to force green.
> **Re-verify with a real `!testme` on the recipe PR too?** If the recipe upgrade PR is still open,
> posting a fresh `!testme` on it after the test PR merges would re-run with the merged tests —
> but you can't merge the test PR (operator does). So the harness-branch verification in (a) is the
> authoritative pre-merge proof. Leave a comment on the recipe upgrade PR noting the test PR is
> open and verified-paired, so the operator knows merging both → green.
> **Re-verify with a real `!testme` on the recipe PR too?** The harness-branch verification in (a)
> is the authoritative pre-merge proof. After it's green, merge the test PR; if the paired recipe
> upgrade PR is still open, optionally post a fresh `!testme` on it (now running with the merged
> tests) as a belt-and-braces confirmation, and leave a comment noting the test PR is merged so
> the operator knows merging the recipe PR → green.
### 5. Tear down any dev deploys (defence-in-depth)
@@ -212,24 +217,26 @@ Write `/srv/cc-ci/.cc-ci-logs/tests-update-<YYYY-MM-DD>.md` and print, leading w
# cc-ci Stale-Test Update — <YYYY-MM-DD>
## Summary
- Swept: N recipes · Stale tests found: N · Test PRs opened + verified: N · Failed: N · Not-stale (dropped): N
## Test PRs to review (NOT merged)
| recipe | stale test | upstream change | test PR | verified |
|--------|-----------|-----------------|---------|----------|
## Test PRs (merged — links for after-the-fact review)
| recipe | stale test | upstream change | test PR (merged) | verified |
|--------|-----------|-----------------|------------------|----------|
| <recipe> | <test-name> | <what changed> | <url> | GREEN (paired with recipe PR <url>) |
## Failed (needs work)
- <recipe> — <test-name>: <reason> (test PR <url> left open, red)
## Not-stale (dropped — was flaky / real recipe bug / CI-server bug)
- <recipe> — <test-name>: <classification> (handed off / noted)
```
End with the report path and a reminder that **nothing was merged** — the test PRs (and their
paired recipe upgrade PRs) await operator review.
End with the report path and **links to every merged test PR + a summary of what changed in each**
(so the operator can review after the fact). Failed/red test PRs are left open, not merged; the
paired recipe upgrade PRs remain operator-owned and unmerged.
## Guardrails
- **Never weaken a test** to turn a red green. The fix makes the test correct for the new upstream
behavior; if that's not possible without weakening, stop and report.
- **Create + verify, NEVER merge.** Each test PR (and any paired recipe upgrade PR) is
operator-merged after review.
- **Create for visibility, verify, then merge directly.** Each test PR is merged only after its
verification is green (the invocation is the authorization); red/unverified PRs stay open. The
paired recipe upgrade PRs are NOT yours to merge. Always report merged-PR links + summaries.
- **Single-writer:** dedicated branch in a separate clone; never push `main`; never touch the
build loops' `/cc-ci` `/cc-ci-adv` clones or `/root/builder-clone`. Use `/root/cc-ci-test-verify`
on the host and `rm -rf` it after.