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

feat(recipe-upgrade): upstream release-notes registry + recipe-README read (recipe-maintainer parity)

Browse Source 
Close the two gaps vs recipe-maintainer's recipe-upgrade-plan:
- Per-recipe release-notes registry at cc-ci-plan/upstream/<recipe>.md (discover the source repo +
  releases/changelog URL for each image once, persist+commit, reuse) — fetch release notes FROM those
  URLs instead of rediscovering ad-hoc each run. Format doc + cryptpad seed included.
- Explicitly read the recipe's README for shipped upgrade/migration notes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
autonomic-bot
2026-06-05 01:28:27 +00:00
parent f4b1befbdd
commit f0716764db
3 changed files with 55 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
.claude/skills/recipe-upgrade/SKILL.md
View File

@ -1,6 +1,6 @@
---
name: recipe-upgrade
description: Upgrade ONE Co-op Cloud recipe end-to-end and verify it on the cc-ci CI server. Researches available upstream upgrades, plans them (breaking changes, migrations, config), implements the bump (image tags + recipe version label + config), opens a recipe PR, and verifies it by posting `!testme` on the PR (real CI; results visible in the PR; iterates up to 3×). DEFAULT: recipe PR only, using existing tests — if a test fails because it is genuinely stale, it leaves an explanatory COMMENT on the PR for the operator (does NOT touch tests). With `--with-tests`: also opens + verifies a PR to update the stale cc-ci test. NEVER merges. The per-recipe worker behind /upgrade-all. Invoke as /recipe-upgrade <recipe> [--with-tests].
description: Upgrade ONE Co-op Cloud recipe end-to-end and verify it on the cc-ci CI server. Researches available upstream upgrades — fetching each image's release notes via a persisted per-recipe registry (cc-ci-plan/upstream/<recipe>.md) + the recipe README — plans them (breaking changes, migrations, config), implements the bump (image tags + recipe version label + config), opens a recipe PR, and verifies it by posting `!testme` on the PR (real CI; results visible in the PR; iterates up to 3×). DEFAULT: recipe PR only, using existing tests — if a test fails because it is genuinely stale, it leaves an explanatory COMMENT on the PR for the operator (does NOT touch tests). With `--with-tests`: also opens + verifies a PR to update the stale cc-ci test. NEVER merges. The per-recipe worker behind /upgrade-all. Invoke as /recipe-upgrade <recipe> [--with-tests].
---
# recipe-upgrade
@ -79,9 +79,18 @@ ssh cc-ci 'export PATH=/run/current-system/sw/bin:$PATH; R=<recipe>; \
- **No upgrades available → stop** (status `SKIPPED — up-to-date`) — after the reconcile above.
- Check `git log HEAD..origin/main` and upstream PRs (`git.coopcloud.tech/coop-cloud/<recipe>/pulls`)
— if someone already started the bump, **re-plan from the tip of `origin/main`**, not from scratch.
- For each service with an upgrade, fetch upstream **release notes** (WebFetch) between current and
target versions and call out **breaking changes / required migrations / new-or-renamed config /
dependency bumps** in an "Operator Action Required" section.
- **Release-notes registry (discover once, reuse — parity with recipe-maintainer's `upstream.md`).**
Read `cc-ci-plan/upstream/<recipe>.md` — a per-image map of source repo + releases/changelog URL. If
it's missing, or an image in `compose.yml` isn't covered (new/renamed service), discover the upstream
project + releases page for each uncovered image (WebSearch the image → its GitHub/source repo →
releases/changelog), **write/update** `cc-ci-plan/upstream/<recipe>.md` and commit it
(`git -C /srv/cc-ci-orch add cc-ci-plan/upstream/<recipe>.md && git -C /srv/cc-ci-orch commit -m "upstream(<recipe>): release-notes sources" && git -C /srv/cc-ci-orch push`).
Format + how it's used: `cc-ci-plan/upstream/README.md`.
- **For each service with an upgrade, fetch the release notes from the registry URLs** (WebFetch)
between current → target versions, and call out **breaking changes / required migrations / new-or-
renamed config / dependency version requirements** in an "Operator Action Required" section.
- **Read the recipe's README** (`~/.abra/recipes/<recipe>/README.md`, if present) for upgrade-specific
instructions, migration steps, or breaking-change notes shipped with the recipe itself.
- Write the plan to `/srv/cc-ci/.cc-ci-logs/upgrades/<recipe>-upgrade-<YYYY-MM-DD>.md`: goal, image
tag table (service / current → new), recipe version bump (+ semver reasoning), required compose/
config changes, risks. (No human review gate — proceed straight to implement.)