From 6acad7b35b16c932ae9d5135fc2afa9c9d4f4900 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Mon, 15 Jun 2026 18:09:41 +0000 Subject: [PATCH] recipe-upgrade: abra recipe release for version bump + upstream release-notes links in PR body cc-ci recipe-upgrade skill now computes the version via 'abra recipe release --dry-run' (not a hand-edit) and requires the PR body to link upstream release notes per service. Bumps the recipe-maintainer submodule pointer to the matching change. --- .claude/skills/recipe-upgrade/SKILL.md | 27 ++++++++++++++++++++++---- cc-ci-plan/JOURNAL.md | 11 +++++++++++ references/recipe-maintainer | 2 +- 3 files changed, 35 insertions(+), 5 deletions(-) diff --git a/.claude/skills/recipe-upgrade/SKILL.md b/.claude/skills/recipe-upgrade/SKILL.md index 43e672a..0114dea 100644 --- a/.claude/skills/recipe-upgrade/SKILL.md +++ b/.claude/skills/recipe-upgrade/SKILL.md @@ -115,7 +115,21 @@ 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 to the new version string from 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.) - `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 @@ -182,9 +196,14 @@ exists for this recipe (branch `upgrade-*`), the new work is pushed onto THAT PR updated + re-tested** — one evolving upgrade PR per recipe, not a second parallel one. Only if none exists is a fresh `upgrade-` PR opened. Unrelated open PRs (e.g. a backup fix) are **NOT** closed or touched — the operator decides on those. The PR's diff is exactly this upgrade against the -real current upstream main. Capture the `PR_URL`. Optionally export `RECIPE_PR_BODY` first (image-tag -table + the planned operator-action notes). Re-running with the same target version updates the -existing same-branch PR rather than duplicating it. +real current upstream main. Capture the `PR_URL`. Export `RECIPE_PR_BODY` first (image-tag table + the +planned operator-action notes) — and **the PR body MUST link the upstream release notes**: for each +upgraded image/service, pull its release-notes URL from the registry `cc-ci-plan/upstream/.md` +(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. ### 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/cc-ci-plan/JOURNAL.md b/cc-ci-plan/JOURNAL.md index 0eead88..c417044 100644 --- a/cc-ci-plan/JOURNAL.md +++ b/cc-ci-plan/JOURNAL.md @@ -674,3 +674,14 @@ session cc-ci-orchestrator-stale can be killed; recipe-mirrors org still private (13:51:14)** — the old 15-min deadlock is gone. deploy-proxy journal: traefik noop-healthy via /api/version → Finished. No failed units; 9/9 infra; endpoints 200. D8 circular-dep DEFINITIVELY fixed. Build sequence complete again (pxgate was 15/15). + +## 2026-06-15 ~18:30 — recipe-upgrade workflow: abra version bump + release-notes links in PR +- Operator: (1) upgrade PR comments must link the relevant upstream release notes; (2) stop hand-editing + the coop-cloud version label — use `abra recipe release -x|-y|-z --dry-run` to COMPUTE the + a.b.c+x.y.z (semver per flag + app image tag), apply on the PR branch, never run non-dry-run (it + publishes upstream). Verified the syntax + dry-run behavior on the live abra first. +- Changed cc-ci recipe-upgrade SKILL.md (§2 bump + §3 PR body) and recipe-maintainer (submodule, pushed + to notplants/recipe-maintainer main): recipe-upgrade-apply, recipe-new-tag, recipe-create-pr, + recipe-upgrade-plan, recipe-upstream. Release-notes URLs come from the per-recipe upstream registry + (cc-ci-plan/upstream/.md ; recipe-info//upstream.md). Also earlier: used-recipes.md + + uptime-kuma marked external (excluded from weekly upgrade). diff --git a/references/recipe-maintainer b/references/recipe-maintainer index c78903b..a26b14c 160000 --- a/references/recipe-maintainer +++ b/references/recipe-maintainer @@ -1 +1 @@ -Subproject commit c78903be92a71cdb4618fe45f00c313eaaefd5b2 +Subproject commit a26b14c2ab434d7548b2838e0cf167cb96a5d21e