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

cctest-recipe-upstream: verify merge-base before rebasing; beware stray upstream main vs master

Browse Source
This commit is contained in:
autonomic-bot
2026-09-14 19:24:24 +00:00
parent 43f2cf074b
commit 2d312b366e
2 changed files with 16 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.opencode/skills/cctest-recipe-upstream/SKILL.md
+8 -10
View File
@@ -72,16 +72,14 @@ In both modes the final output is a set of commands for the operator to run on a
push access to `git.coopcloud.tech`** — always print them, even when everything local is
already prepared.
**History-divegence check before emitting the compare URL.** The autonomic recipe-maintainer
mirrors' `main` can share only a distant ancestor with upstream `main` (same work re-committed
with different hashes as the mirror was synced/rebuilt). A 3-dot compare
`main...<head_ref>` from the raw mirror branch then shows the ENTIRE diverged history, not the
one upgrade commit. Guard: while preparing, run
`git merge-base <head_ref> <base_ref>`; if the result is older than a few commits below upstream
`origin/main`, cherry-pick the upgrade commit(s) onto fresh upstream `origin/main` (branch
`<head_ref>-rebased`), push THAT to the autonomic mirror, and emit the fetch/push/compare commands
using the rebased branch instead of the raw one. Also fix the stale `origin/main` wording above:
the upstream base branch may be `master`, not `main` — derive it from the remotes.
**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),
scripts/gen-cctest-skills.py
+8 -10
View File
@@ -100,16 +100,14 @@ In both modes the final output is a set of commands for the operator to run on a
push access to `git.coopcloud.tech`** — always print them, even when everything local is
already prepared.
**History-divegence check before emitting the compare URL.** The autonomic recipe-maintainer
mirrors' `main` can share only a distant ancestor with upstream `main` (same work re-committed
with different hashes as the mirror was synced/rebuilt). A 3-dot compare
`main...<head_ref>` from the raw mirror branch then shows the ENTIRE diverged history, not the
one upgrade commit. Guard: while preparing, run
`git merge-base <head_ref> <base_ref>`; if the result is older than a few commits below upstream
`origin/main`, cherry-pick the upgrade commit(s) onto fresh upstream `origin/main` (branch
`<head_ref>-rebased`), push THAT to the autonomic mirror, and emit the fetch/push/compare commands
using the rebased branch instead of the raw one. Also fix the stale `origin/main` wording above:
the upstream base branch may be `master`, not `main` — derive it from the remotes.
**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),