Repository navigation
sync-skill: stack a directed sync on an open sync PR; recognize tag-tip workflow swaps - #125
Merged
Merged
Conversation
… recognize tag-tip workflow swaps
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
10 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ELI5
The v1.4.230 sync hit two situations the sync skill didn't cover. This writes down what worked so the next run doesn't have to work it out again.
What Changed
SKILL.mdStep 2. The rule that stops a run while an older sync PR is open now also says what to do when a person tells the run to go ahead anyway: build the newer tag's merge on top of the older PR's branch and open a new PR. The unattended stop itself is unchanged.references/sync-lessons.md. A new entry for tags whose last commit swaps in upstream main's workflow files. It covers how to spot one (the commit just belowrelease: <tag>touches only.github/workflows/) and the fix: take that commit's parent for those workflows.Why
Both are reproducible and cost this run real time.
d3dfc479b8, mergedv1.4.230with-X ours, and opened sync: absorb upstream v1.4.230 #122. Merging sync: absorb upstream v1.4.230 #122 (merge commit0316f51c75) landed both tags. GitHub then marked sync: absorb upstream v1.4.227 #120 merged, because its head became an ancestor ofmain.git merge-base --is-ancestor v1.4.230 origin/mainpasses, and the merge commit has two parents.a220036892under v1.4.227 and597425845eunder v1.4.230. On PR sync: absorb upstream v1.4.230 #122 it turned 8 workflow-contract tests red on files byte-identical to the tag. It also added adependency_isolationjob topr.ymlthat failedverifyon every PR with "missing or invalid selection". Taking597425845e^for the upstream-owned workflows cleared the 8 tests (sync commitd22754e8ef). Dropping the job clearedverify(e08c6bf691).Alternatives I rejected: taking main's scripts to match main's workflows (pulls in unreleased trunk), and editing the red tests (they're upstream-owned and correct for their own release).
Linked Issue
N/A (fork-internal skill notes)
Visual Proof
N/A (documentation only, no UI change)
Testing
Docs-only change under
.claude/skills/sync-upstream/. The claims can be checked withgit show --stat 597425845e,git show --stat a220036892,git log --oneline -3 v1.4.230, andgh pr view 120 --repo zpyoung/orca --json state.This PR is left open for review. The sync run doesn't merge it.