cc-ci-orchestrator/.opencode/skills/cctest-recipe-upstream/SKILL.md

name, description

name	description
cctest-recipe-upstream	[recipe-maintainer/cctest] From a git.autonomic.zone review-PR URL, fetch the branch + tag locally and emit the commands to open the upstream PR on git.coopcloud.tech (Wraps the autonomic-recipe-maintainer skill /recipe-upstream; runs against the cctest test server + ARM sandbox, not cc-ci. Invoke as /cctest-recipe-upstream.)

cctest-recipe-upstream (cctest wrapper)

Canonical procedure: references/recipe-maintainer/.opencode/skills/recipe-upstream/SKILL.md — read it and follow it. This wrapper only sets context + policy.

Context: this is an autonomic-recipe-maintainer (ARM) skill. It operates on the recipe-maintainer cctest test server / local abra sandbox — NOT on the cc-ci CI server or its shared swarm. Execute with the submodule as your working directory: cd /srv/cc-ci-orch/references/recipe-maintainer. If the ARM environment is not yet configured on this host (settings.toml from settings.toml.example, sandbox/test instances), run /cctest-intro / /cctest-setup-sandbox first.

Unified policy (same as cc-ci — no differences):

• Recipe PRs are NEVER merged by an agent. Every flow ends at an open PR; the operator reviews and merges. This is ARM's own rule too ("PRs are reviewed and merged manually by a human afterwards — never pushes to upstream or merges anything"); ARM's "no human review in the middle" wording refers only to skipping the mid-run plan confirmation, not to merging.
• Never touch cc-ci infrastructure (the CI server, its swarm, /root/* clones, the weekly timers) from an ARM skill — cc-ci work goes through the cc-ci skills.
• The submodule is pinned: don't commit into it from here; upstream ARM changes arrive via a deliberate submodule bump + scripts/gen-cctest-skills.py regeneration.

Sandboxed vs non-sandboxed mode. This skill needs only git + (optionally) the Gitea API — not the test server — so it can run either way. Probe, then follow that branch:

• Sandboxed (ARM env configured: test-ssh/.testenv with GITEA_USERNAME/GITEA_PASSWORD/ GITEA_URL, sandbox/test instances): the canonical recipe-upstream script in references/recipe-maintainer/.claude/commands/recipe-upstream.md runs as written. Note its WORKSPACE probing expects /workspace or ~/Documents/recipe-maintainer; on a bare host pass the submodule dir explicitly instead.
• Non-sandboxed (no ARM env on the host — e.g. the orchestrator, where the recipe-maintainer checkout is only a pinned submodule): no sandbox/test instances are needed and NONE of the setup skills are. Recipe-maintainer mirrors on git.autonomic.zone are publicly readable, so:
  1. Check out the recipe if missing: abra recipe fetch <recipe> (lands in ~/.abra/recipes/<recipe>) — or a plain anonymous git clone https://git.autonomic.zone/recipe-maintainers/<recipe>.git if abra is unavailable.
  2. Fetch the PR head branch from the mirror anonymously — no credentials in the remote URL: git remote add gitea https://git.autonomic.zone/recipe-maintainers/<recipe>.git (remote update rather than re-add if it exists), then git fetch gitea +refs/pull/<N>/head:refs/heads/<head_ref>.
  3. Fetch PR metadata (head/base refs, merged flag, release bump line) from https://git.autonomic.zone/api/v1/repos/recipe-maintainers/<recipe>/pulls/<N> — unauthenticated; use bot creds only if the repo turns out to be private (orchestrator hosts can read them from /srv/cc-ci-orch/.testenv — never written anywhere else).
  4. Everything else in the canonical script (origin/dev remote setup, release recommendation, emitted next-steps) is identical.

Every time the branch was prepared here, remember it exists only on this host — the operator's machine must fetch it first. Always emit this step 0 before the push step (anonymous public fetch, no credentials needed):

  # 0. On a machine WITHOUT the branch pre-fetched, get it from the autonomic mirror
  #    (fetch by URL — works regardless of what the local remotes are named):
  cd <local checkout of the recipe>
  git fetch https://git.autonomic.zone/recipe-maintainers/<recipe>.git +refs/pull/<PR_NUM>/head:refs/heads/<HEAD_REF>
  git checkout <HEAD_REF>

If the operator's checkout does NOT yet have the mirror remote, emit once before the fetch:

  git remote add gitea https://git.autonomic.zone/recipe-maintainers/<recipe>.git

In both modes the final output is a set of commands for the operator to run on a machine with push access to git.coopcloud.tech — always print them, even when everything local is already prepared.

Verify the merge-base BEFORE rebasing — bases can be traps. Upstream repos can carry a stray, divergent main ALONGSIDE the real master base branch. Rebase targets must be chosen by evidence: git ls-remote origin | grep -E 'refs/heads/(main|master)$', then git merge-base <head_ref> origin/<candidate> — the correct base is the one where the upgrade branch's merge-base is its tip's parent (i.e. <head_ref> is already directly on that line — then NO cherry-pick is needed, the raw branch compares clean). Cherry-picking onto the wrong base produces the very messy 3-dot compare this guard exists to prevent (real case: gitea — first "rebase" landed on a stray main and had to be redone onto master).

Branch-name mismatch mirror vs upstream. The mirror and upstream can use different base-branch names (gitea: mirror main, upstream master). When emitting step 3 (the post-merge release), NEVER hardcode main — derive the upstream default branch from the existing remotes (git remote show origin or git ls-remote --symref origin HEAD) and emit git checkout <that>; git fetch origin; git merge --ff-only origin/<that>; before abra recipe release.