From 2f2225e4666a8a48c33c1e3664ff20a87109d622 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Mon, 15 Jun 2026 18:38:27 +0000 Subject: [PATCH] recipe-upgrade: defer version bump to operator's final 'abra recipe release' MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit §2 no longer bumps the coop-cloud version label in the recipe PR (no --dry-run compute, no tag). It records the recommended 'abra recipe release -' (no --dry-run) in the PR body (§3) as the operator's final publish step — run after the upstream PR merges, it bumps the label + tags + pushes in one go. Bumps recipe-maintainer submodule to 9daddac (same change across its /recipe-upstream, -upgrade-apply, -upgrade-plan, -new-tag). --- .claude/skills/recipe-upgrade/SKILL.md | 41 ++++++++++++++------------ references/recipe-maintainer | 2 +- 2 files changed, 23 insertions(+), 20 deletions(-) diff --git a/.claude/skills/recipe-upgrade/SKILL.md b/.claude/skills/recipe-upgrade/SKILL.md index 0114dea..be9fed9 100644 --- a/.claude/skills/recipe-upgrade/SKILL.md +++ b/.claude/skills/recipe-upgrade/SKILL.md @@ -115,25 +115,26 @@ On cc-ci's `~/.abra/recipes/` (wrap every abra call per the pseudo-TTY b `docker manifest inspect`), then write `image: :@`. If the app and its digest-pinned sidecars must move together (e.g. immich-server ↔ its `postgres:…-vectorchord…` DB), bump them as a matched, compatibility-checked set per the plan. -- **Bump the `coop-cloud.${STACK_NAME}.version` label — COMPUTE the version with `abra recipe release`, - do NOT hand-write/sed it.** Run it `--dry-run` so it computes the correct `a.b.c+x.y.z` (the recipe - SEMVER bumped per the flag + the app service's image tag, which abra reads from compose) WITHOUT - publishing — pick `-x`/`-y`/`-z` from the upgrade's nature per the plan (breaking→`-x` major, new - feature→`-y` minor, patch/security→`-z` patch): - `script -qec "abra recipe release -y --dry-run -n" /dev/null` - prints e.g. `INFO dry run: not syncing label 3.4.1+2.26.3 for recipe ` and changes nothing. - Then set that exact computed `a.b.c+x.y.z` as the `coop-cloud.${STACK_NAME}.version` label and commit - it on the PR branch (this replaces the old hand-picked-semver step). - ⚠️ **Never run `abra recipe release` WITHOUT `--dry-run` here** — a real (non-dry-run) release also - tries to PUBLISH (push the new version to the recipe's git origin), and our workflow NEVER pushes the - recipe's upstream/`main`; we open a PR from a branch on the mirror. So use release only to COMPUTE the - version (so it's correct), keep the existing branch→mirror-PR mechanics, and let the label edit + commit - ride on the PR branch as before. (`abra recipe upgrade -n` for the image-tag bumps above is - unchanged.) +- **Do NOT bump the `coop-cloud.${STACK_NAME}.version` label in the PR — record the recommended release + bump instead.** The version bump + tag + publish are all done at the very end by a single real + `abra recipe release` (run by the operator after the upstream PR merges — see recipe-maintainer's + `/recipe-upstream`); the upgrade PR only carries the image-tag + config changes. So **leave the version + label untouched** and just **decide the semver bump** from the upgrade's nature per the plan + (breaking→`-x` major, new feature→`-y` minor, patch/security→`-z` patch). Put the recommended release + command — `abra recipe release -` (NO `--dry-run`) — in the PR body (§3) so the operator + can run it verbatim to publish. At release time `abra recipe release` computes the final `a.b.c+x.y.z` + from the current label + the flag + the app image tag and syncs the label then. + ⚠️ **Never run `abra recipe release` in this skill** (with or without `--dry-run`) — a real release + PUBLISHES (pushes the new version to the recipe's git origin) and we NEVER push the recipe's + upstream/`main`; we open a PR from a branch on the mirror. Publishing is the operator's final step. + (`abra recipe upgrade -n` for the image-tag bumps above is unchanged.) - `script -qec "abra recipe lint -C -n" /dev/null` — fix obvious lint errors; if unfixable, record it and continue. -- Commit on a branch: `git commit -m "chore: upgrade to "` (the commit message drives the - PR branch name `upgrade-`). Do **not** push to upstream; do **not** tag-push. +- Commit on a branch describing the image-tag/config changes, e.g. + `git commit -m "chore: upgrade to "`. Do **not** mention a recipe version (none is + bumped here) and do **not** create/push a tag — the branch name falls back to `upgrade-` (see + `open-recipe-pr.sh`). Do **not** push to upstream; the version bump + tag + publish are the operator's + final `abra recipe release` step. ### 2b. Direct deploy + inspect on cc-ci — live feedback BEFORE CI (recipe-maintainer style) Before opening the PR / running `!testme`, deploy the WIP recipe **directly** on the cc-ci server and @@ -202,8 +203,10 @@ upgraded image/service, pull its release-notes URL from the registry `cc-ci-plan (between the current → new version) and include one explicit line per service in the body, e.g. `**Upstream release notes:** →: `. These links go in the PR comment/body itself (so a reviewer sees exactly what changed upstream) — do NOT relegate them to the plan/report -only. Re-running with the same target version updates the existing same-branch PR rather than -duplicating it. +only. The body must **also** carry the recommended release command — `abra recipe release -` +(NO `--dry-run`) — on its own line, since the PR does not bump the version label: this is the operator's +final publish step (bumps the label + tags + pushes) after the upstream PR merges. Re-running with the +same target version updates the existing same-branch PR rather than duplicating it. ### 4. VERIFY by running `!testme` ON THE PR (results visible in the PR; iterate ≤3×) Trigger the **real** CI on the recipe PR by posting `!testme` — the bridge runs the harness on cc-ci diff --git a/references/recipe-maintainer b/references/recipe-maintainer index a26b14c..9daddac 160000 --- a/references/recipe-maintainer +++ b/references/recipe-maintainer @@ -1 +1 @@ -Subproject commit a26b14c2ab434d7548b2838e0cf167cb96a5d21e +Subproject commit 9daddac466c79ada28e289e0a002e9fddbe38301