Repository navigation
Derive release merge wait from CI duration and refresh a safe main advance once - #172
Conversation
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Reviewer's GuideThe release workflow now derives a conservative merge wait from recent Node 22/26 CI durations and can safely rebase and revalidate a release branch once when main advances, with strict metadata guards, head-specific publishing, deadline restart, and extensive real-git/workflow regression coverage. Sequence diagram for measured release merge and safe main refreshsequenceDiagram
participant Workflow
participant GitHubAPI
participant Policy
participant Git
participant ReleasePR
Workflow->>GitHubAPI: gh api successful main push runs
GitHubAPI-->>Workflow: test (22)/(26) job timings
Workflow->>Policy: deriveReleaseMergeWait(jobs)
Policy-->>Workflow: wait_seconds and timing summary
Workflow->>Git: refresh_release_base
Git->>Policy: assertSafeReleaseAdvance(base, main)
Policy-->>Git: safe advance or error
alt main advanced safely
Git->>Git: git rebase current_main_sha
Git->>GitHubAPI: git push --force-with-lease
Git->>ReleasePR: restart measured merge wait
else no main advance
Workflow->>ReleasePR: poll required checks and merge
end
ReleasePR-->>Workflow: merged head SHA
Workflow->>Workflow: verify merged release
Flow diagram for release merge wait derivationflowchart TD
A[Successful main push CI runs] --> B["Collect test (22) and test (26) durations"]
B --> C[Compute nearest-rank p95]
C --> D[Add max of 900 seconds or 25% margin]
D --> E[Bound wait to 60–120 minutes]
E --> F[Record samples p95 margin and bounds]
F --> G[Use measured wait for release merge]
G --> H{Safe main advance?}
H -- No --> I[Continue polling or merge]
H -- Yes --> J[Rebase and push with head-specific lease]
J --> K[Restart full measured wait]
K --> L[Require checks on new head]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
unbraind
left a comment
There was a problem hiding this comment.
Orchestrator review (built-in Claude review agent, verified by the orchestrator; bots are not waited for since 2026-10-22):
Pre-merge review (codex gpt-6.1-sol read-only review agent; merged by the orchestrator's pipeline after a MERGE verdict and a private-data scan of the added lines).
VERDICT: MERGE
FINDINGS:
- none
SUMMARY: The PR derives a bounded merge wait from CI durations and permits one guarded release-branch refresh with a restarted deadline. Tests cover timing fallbacks, reverted metadata changes, conflicts, repeated advances, and refreshed merge SHAs; I reviewed but did not execute them.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
Daily Release PR #171 exhausted the fixed 30-minute merge wait while required tests were still running. Earlier main advances also aborted otherwise safe release preparation or left the release PR BEHIND.
The job now measures successful
test (22)andtest (26)jobs from the last 20 successful main push CI runs. It uses nearest-rank p95 plus the larger of 15 minutes or 25%, bounded to 60–120 minutes under an explicit 360-minute job timeout, and records the derivation in the log and job summary. A read-only execution of the workflow measurement step found 40 samples: p95 1,859 seconds plus 900 seconds margin, yielding the 60-minute floor.A safe main advance during preparation or waiting rebases the release branch once and restarts the full measured wait. A published branch update uses the previous head as its push lease, and the merge API receives the new head SHA. Every intervening commit is checked for package/lock release-version changes or changes to the changelog, manifest or release notes, including changes later reverted. Metadata drift, conflicts, non-ancestor main and a second advance abort.
Validation:
npm run release:checkandbun run release:check, with isolated HOME and git configuration: 1,045 passed each, zero failures or skips. Exact 100/100/100/100 coverage across 19 authored modules: 11,640 lines/statements, 337 functions and 3,964 branches. Both gates also passed lint, docstrings, zero duplication, privacy, audit, packing, changelog and publish-attestation checks. Independent candidate snapshots produced the same package hash.node --test test/release-merge-policy.test.ts test/daily-release-plan.test.ts test/release-approval.test.ts test/release-workflow.test.ts: 60/60, also executed through the linked pm test runner. The tests execute the workflow's own shell and use real temporary git histories and a real non-git pm tracker.bun test --timeout 600000 test/release-merge-policy.test.ts: 24/24 new regressions.The new workflow regressions run in the existing CI release gate on Node 22 and 26. CI run 39992427193 passed 4/4 matrix jobs, including 2/2 required checks, on
da42c756b9aa1615e26e69527c2f4eea09b7c8e1. The current check rollup is 8 success, 2 skipped and 1 neutral, with no failures or pending checks. Skipped, neutral and unavailable automated reviews do not establish review approval; review remains pending. After merge, the orchestrator dispatches Daily Release.PM item: pm-github-release-merge-wait (candidate evidence). The item remains in progress and its claim is released for orchestrator verification.
Summary by Sourcery
Make Daily Release waits adaptive to CI performance and safely recover once from eligible main-branch advances.
New Features:
Bug Fixes:
Enhancements:
Documentation:
Tests:
Chores:
Summary by cubic
Fixes the Daily Release workflow's fixed 30-minute merge wait, which expired while required tests were still running on PR #171. The wait is now derived from measured CI durations, and a safe main advance may refresh the release branch once.
test (22)andtest (26)job durations from the last 20 successful main push runs, plus max(15 min, 25%), bounded to 60–120 minutes under the job's 360-minute timeout; the derivation is logged and written to the job summary.Validation:
npm run release:checkandbun run release:checkeach passed 1,045 tests with exact 100/100/100/100 coverage across 19 modules; the workflow-focused pm test passed 60/60 and the new regressions passed 24/24 under Bun. Four behavioral revert controls failed as expected, and both package dry runs produced the same package hash.Written for commit 9b9a623. Summary will update on new commits.