ci: keep the release-please PR rebased onto main (LAB-335)

[27Bslash6]

Closes LAB-335.

Root cause of #214's manual rebase (verified, not assumed)

• Not a branch-protection rule: the main ruleset has strict_required_status_checks_policy: false — there is no "require branches up to date" rule.
• Not a git conflict: git merge-tree of the pre-rebase head (635c8d08 + its lockfile-sync commit, recovered from the force-push timeline) against main exits clean, and no lockfile-touching commit landed on main after the last bot regeneration.
• Confirmed: silent drift on non-releasable commits. The PR timeline shows a bot force-push regeneration within ~30 s of every releasable commit (4/4: feat: checksum FFI binding + benchmark (cachekit-core#13 Phase 2) #212, fix(serializers): AutoSerializer sets compressed metadata from the actual ByteStorage codec #211, fix(security): fail closed on plaintext frames when encryption is enabled (LAB-241) #215/LAB-241, fix(config): enforce l1_max_size_mb + max_value_size, remove dead zlib/chunk knobs (LAB-109) #217/LAB-109, fix(decorators): L1-only mode (backend=None) honors L1CacheConfig SWR + max_size_mb (LAB-106) #219/LAB-106 window), and none for test: test: stop docs conftest leaking CACHEKIT_MASTER_KEY into the env (#205) #206 / chore: chore: benchmark suite — fix harness, one-folder consolidation, measurement integrity + GIL + unified runner #188 — after which the branch sat 2 commits behind for ~8 h until 27Bslash6 force-pushed a manual rebase at 2026-07-19T23:18Z. release-please compares its generated file content (changelog/version), which hidden commit types don't change, so it never notices the stale base.

The lockfile-conflict scenario (LAB-64: a Renovate lockfile bump on main colliding with the branch's chore: sync lockfiles commit) did not fire this time, but it is real — simulation below proves a plain rebase conflicts when a main-side lockfile edit overlaps the sync commit's hunks (e.g. the resolver-drift lines the sync commit carries).

Change

sync-lockfiles becomes sync-release-pr, a superset:

• Runs on every push to main while a release PR is open. The PR is discovered at runtime (gh pr list, head prefix release-please--) because release-please only sets outputs.pr on runs where it regenerated — exactly the complement of the runs this job must cover. No open release PR → clean early exit before any checkout/toolchain setup.
• Rebases the branch onto main, but regenerates the lockfiles instead of rebasing them: the branch's own chore: sync lockfiles with release commit is dropped pre-rebase and rebuilt from the bumped manifests (uv lock + cargo update -p cachekit-rs, same commands as before). Lockfile changes on main can therefore never conflict with the branch — the conflict class is removed structurally, not handled.
• On regeneration runs (release-please just force-pushed), the branch is already on main's tip: the rebase no-ops and the job reduces to exactly the old sync-lockfiles behaviour.
• A conflict outside the lockfiles (release-please's version/changelog files — main never edits those regions between releases) aborts the rebase and fails loudly rather than guessing.

Guard rails (the issue's ACs)

• Gated on a release PR existing — runtime discovery; skipped entirely when a release was just cut (release_created == 'true', the PR was merged away) and on workflow_dispatch (force_release re-runs must not touch the open PR).
• No churn loop — the job pushes to the release branch, not main, so this workflow can't re-fire; the next release-please regeneration force-push simply supersedes the rebased commits with identical-content ones built from latest main. needs: release-please keeps it ordered after any same-run regeneration, and prs_created == 'true' runs skip the rebase by the is-ancestor guard.
• No spurious wheel matrix / check runs — every push-triggered workflow in the repo is scoped to main/develop; a release-branch push triggers only the PR's own pull_request checks (CI, Security Fast — the required ones), via the existing App token so they actually re-trigger (default GITHUB_TOKEN pushes don't). The wheel matrix stays gated on release_created.
• No push when current — an up-to-date branch with in-sync lockfiles exits without pushing (verified below), so no gratuitous review dismissal.
• No racing writers — force-with-lease (refuses to clobber anything that moved the branch since checkout) + a job-level concurrency group serializing overlapping main pushes.

prs_created/pr job outputs are removed — the replaced job was their only consumer.

Verification (faithful simulation against the real #214 state)

Local bare-origin replay using the exact run: script extracted from the workflow YAML (actionlint + zizmor clean — zizmor finding count identical to the pre-change file):

1. chore(main): release 0.12.0 #214 replay: reconstructed the pre-rebase head (635c8d08 + cherry-picked lockfile commit, base a5a347c) with main at 4962d9b. Script output: lockfile commit dropped, release commit rebased, lockfiles regenerated (cachekit/cachekit-rs → 0.12.0), force-with-lease push. Result is a clean merge-tree against main and matches the tree of the human's actual manual rebase (8af4832b) except one uv.lock resolver-marker line that is a local-uv-version artifact (CI's setup-uv produces the canonical output, as the old job did).
2. LAB-64 lockfile conflict: crafted a main-side uv.lock edit on the same line the sync commit rewrites — a plain git rebase conflicts; the drop-and-regenerate path converges to a mergeable branch with no manual step.
3. Regeneration path + idempotency: a fresh release commit on main's tip gets exactly the old lockfile-sync commit (normal fast-forward push); an immediate re-run reports "already current; nothing to push" and pushes nothing.

Scope

CI/release config only — no product code, crypto, protocol, wire-format, or branch-protection changes. Sibling repos (ts/rs/core/saas) are a follow-up per the issue's non-goals.

Summary by CodeRabbit

• Chores
  • Improved release automation to keep release branches synchronised with the main branch.
  • Lockfiles are now refreshed automatically during release preparation.
  • Added safeguards to prevent competing updates and preserve unrelated release changes.
  • Release builds and publishing continue to follow the existing workflow.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 20 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 10ffde21-7a0e-4e70-b2c3-734ef3cdb248

📥 Commits

Reviewing files that changed from the base of the PR and between 64ef7bd and 9dac232.

📒 Files selected for processing (1)

• .github/workflows/release-please.yml

Walkthrough

The release workflow removes obsolete job outputs and replaces lockfile syncing with a concurrency-controlled job that discovers the open release PR, rebases its branch onto main, regenerates lockfiles, and safely pushes updates.

Changes

Release PR synchronisation

Layer / File(s)	Summary
Release workflow outputs and gating .github/workflows/release-please.yml	Removes the prs_created and pr outputs and adds the sync-release-pr job with updated push conditions and concurrency control.
Release branch reconciliation .github/workflows/release-please.yml	Finds the open release branch, rebases it onto origin/main, removes a prior generated lockfile commit when applicable, regenerates lockfiles, commits only detected changes, and pushes with --force-with-lease.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GitHubActions
  participant GitHubPRAPI
  participant ReleasePRBranch
  participant MainBranch
  GitHubActions->>GitHubPRAPI: Find open release-please branch
  GitHubActions->>ReleasePRBranch: Check out release branch
  GitHubActions->>MainBranch: Fetch origin/main
  GitHubActions->>ReleasePRBranch: Rebase onto origin/main
  GitHubActions->>ReleasePRBranch: Regenerate lockfiles
  GitHubActions->>ReleasePRBranch: Force-push with lease

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise and accurately summarises the main CI change.
Description check	✅ Passed	The description thoroughly explains the change, motivation, verification, and scope.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch agent/winston/16fafdaf

---

_{Comment @coderabbitai help to get the list of available commands.}

[27Bslash6]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[27Bslash6]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[27Bslash6]

@coderabbitai full review

[coderabbitai]

✅ Action performed

Full review finished.

---

You're currently rate limited under our Fair Usage Limits Policy. Your recent PR review activity is in the 95th percentile or higher among CodeRabbit users, so adaptive limits apply. Your next review will be available in 24 minutes.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/release-please.yml:
- Around line 123-129: Update the “Checkout release PR branch” actions/checkout
step to set persist-credentials to false, then ensure authentication is
explicitly restored only on the final push step using the required token.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 1e9fb593-8f9c-467c-a52a-2a10b063802d

📥 Commits

Reviewing files that changed from the base of the PR and between 269aecf and 64ef7bd.

📒 Files selected for processing (1)

• .github/workflows/release-please.yml

[27Bslash6]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.