Add /recipe-upgrade + /upgrade-all skills (cc-ci-gated upgrades, never merge)
Per-recipe and fleet-wide upgrade skills modelled on recipe-maintainer's
recipe-upgrade-full / recipe-upgrade-cron-all, but gated by the cc-ci CI server
and inheriting ci-test-review's create+verify+never-merge discipline.
- recipe-upgrade/: plan (release notes, breaking changes) -> implement (abra
recipe upgrade + version bump + config, lint) -> open the recipe PR -> VERIFY
green on cc-ci (full suite cold against the PR head via verify-pr.sh). If the
upgrade is correct but a cc-ci TEST went stale, also update the test, verify
it, and open a second PR to recipe-maintainers/cc-ci. Never merges; never
weakens a test; prefers a recipe-only PR. Emits a parseable RESULT line.
+ open-recipe-pr.sh: adapted recipe-create-pr; runs on cc-ci (has the recipe
checkout + bot token), creds passed from the orchestrator .testenv;
force-syncs the mirror main so the PR diff is exactly the upgrade.
- upgrade-all/: weekly fan-out — enumerate enrolled recipes, survey upgrades,
run /recipe-upgrade per upgradeable recipe via subagent (sequential default,
--parallel / --dry-run), collect into one PR-list summary. Coordination +
single-writer + shared-Swarm-teardown guardrails; built for a weekly cron.
- ci-test-review/verify-pr.sh: pass SRC (recipe-maintainers/<recipe>) alongside
REF so the harness clones the mirror PR head correctly (its real contract).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: upgrade-all
|
||||
description: Weekly autonomous upgrade run for the cc-ci CI server. Surveys every enrolled recipe for available upstream upgrades, then runs /recipe-upgrade on each upgradeable one via a subagent — plan, implement, verify green on cc-ci, open a recipe PR (and, only if a cc-ci test went stale, a verified cc-ci test PR). Collects results into one summary listing every PR to review. Sequential by default (shared Swarm); --parallel to fan out; --dry-run to preview. NEVER merges. Built to run once weekly on a cron. Invoke as /upgrade-all.
|
||||
---
|
||||
|
||||
# upgrade-all
|
||||
|
||||
The cc-ci analogue of recipe-maintainer's `/recipe-upgrade-cron-all`: an unattended **weekly** pass
|
||||
that keeps every enrolled recipe current, with **cc-ci as the test gate** and a human in the loop only
|
||||
where it matters — **PR review**. It surveys upgrades, runs `/recipe-upgrade <recipe>` per upgradeable
|
||||
recipe, and writes one summary of every PR to review. It **never pushes upstream and never merges**.
|
||||
|
||||
Drives cc-ci over `ssh cc-ci`. Logs/summary go to `/srv/cc-ci/.cc-ci-logs/upgrades/`.
|
||||
|
||||
## Arguments (optional `$ARGUMENTS`)
|
||||
- A space-separated list of recipe names → only those (else all enrolled recipes).
|
||||
- `--dry-run` → survey + print what WOULD upgrade; spawn nothing.
|
||||
- `--parallel` → fan out all per-recipe subagents at once (faster, more host load — see safety below).
|
||||
|
||||
## 1. Build the candidate list
|
||||
Enrolled recipes = the cc-ci `tests/<recipe>/` dirs (same set `ci-test-review` sweeps):
|
||||
```
|
||||
ssh cc-ci 'cd /root/cc-ci/tests && ls -d */' | sed 's#/##' | grep -vE '^(_generic|unit|__pycache__)$'
|
||||
```
|
||||
(or the names passed in `$ARGUMENTS`). For each, on cc-ci, check availability — skip dirty/up-to-date:
|
||||
```
|
||||
ssh cc-ci 'export PATH=/run/current-system/sw/bin:$PATH; \
|
||||
git -C ~/.abra/recipes/<r> status --short; \
|
||||
abra recipe fetch <r> --force; \
|
||||
abra recipe upgrade <r> -m -n'
|
||||
```
|
||||
Build `RECIPES_TO_UPGRADE` = recipes with a **clean worktree** AND **≥1 available upgrade**. Others go
|
||||
to `SKIPPED_UPFRONT` with a reason (`dirty-worktree`, `up-to-date`, `not-fetchable`).
|
||||
|
||||
## 2. Print the plan
|
||||
A table — Recipe | Status (will upgrade / skipped:reason) | Available upgrade(s) — plus the mode
|
||||
(`Sequential` default / `Parallel`). If `--dry-run`, **stop here**.
|
||||
|
||||
## 3. Upgrade each recipe via a subagent
|
||||
For each recipe in `RECIPES_TO_UPGRADE`, spawn an Agent (`subagent_type: "general-purpose"`,
|
||||
description `"Upgrade <recipe> on cc-ci"`) with a prompt like:
|
||||
|
||||
> Run the `/recipe-upgrade <recipe>` skill end-to-end
|
||||
> (`/srv/cc-ci/.claude/skills/recipe-upgrade/SKILL.md`): plan, implement, **verify green on cc-ci**,
|
||||
> open a recipe PR, and — only if the upgrade is correct but a cc-ci test went stale — open a verified
|
||||
> cc-ci test PR too. Drive cc-ci over `ssh cc-ci`. Do NOT prompt. Do NOT push upstream. Do NOT merge.
|
||||
> Print exactly one `RESULT:` line as your final line (the SUCCESS / SUCCESS+TESTPR / FAILED / SKIPPED
|
||||
> forms from the recipe-upgrade skill).
|
||||
|
||||
- **Sequential (default):** one Agent at a time; wait, collect its `RESULT:`, then the next. If the
|
||||
Agent tool call itself errors, record `FAILED — agent tool error` and continue. One failure never
|
||||
aborts the run.
|
||||
- **Parallel (`--parallel`):** emit all Agent calls in one message (no `run_in_background` — you need
|
||||
the results). Failures are isolated per recipe.
|
||||
|
||||
## 4. Collect results
|
||||
Parse each final `RESULT:` line into SUCCESS / SUCCESS+TESTPR / FAILED / SKIPPED. A subagent that
|
||||
emitted no `RESULT:` line → `FAILED — no result emitted`.
|
||||
|
||||
## 5. Write + print the summary
|
||||
Write `/srv/cc-ci/.cc-ci-logs/upgrades/upgrade-all-<YYYY-MM-DD>.md` and print it, **leading with the
|
||||
PR list** (the actionable output):
|
||||
```markdown
|
||||
# cc-ci Weekly Upgrade Run — <YYYY-MM-DD>
|
||||
## Summary
|
||||
- Considered: N · Upgraded (PR opened): N · With cc-ci test PR: N · Failed: N · Skipped: N
|
||||
## PRs to review (NOT merged)
|
||||
- <recipe> <old> → <new> — recipe PR: <url> [+ cc-ci test PR: <url>]
|
||||
## Failed (investigate)
|
||||
- <recipe> — at <step>: <reason> (log: .cc-ci-logs/upgrades/<recipe>-upgrade-<date>.md)
|
||||
## Skipped
|
||||
| recipe | reason |
|
||||
```
|
||||
End with the report path and a reminder that **nothing was merged**.
|
||||
|
||||
## Safety / coordination (this matters — shared host with the build loops)
|
||||
- **Sequential is the default for a reason.** Recipe deploys are **stateful on the shared Swarm** and
|
||||
parallel deploys can OOM/collide. Between sequential recipes, the per-recipe `recipe-upgrade` tears
|
||||
down what it deployed; verify a recipe is undeployed before the next starts (`abra app ls` on cc-ci).
|
||||
- **Single-writer:** every PR (recipe or cc-ci test) is on a dedicated branch; **never push `main`**,
|
||||
never touch the build loops' `/cc-ci` `/cc-ci-adv` working clones or their in-flight state.
|
||||
- **Contention with active loop development:** while the loops are still building cc-ci, this run
|
||||
competes for the host. Prefer a quiescent window; if a recipe fails due to contention it's simply
|
||||
retried next week. (Once cc-ci is built and the loops are idle, this is the steady-state weekly job.)
|
||||
- **Never merges**; failures/ skips are surfaced and retried next week — safe to re-run anytime.
|
||||
|
||||
## Cron
|
||||
Designed for a weekly Claude Code scheduled task (configured separately) that invokes `/upgrade-all`
|
||||
in `/srv/cc-ci`. Re-running is idempotent: already-current recipes report `SKIPPED — up-to-date`;
|
||||
recipes with an open PR for the same branch report the existing PR rather than duplicating it.
|
||||
Reference in New Issue
Block a user