Repository navigation
Add next branch workflow (RFD #142) - #4112
Conversation
| # Something merged into next meanwhile. | ||
| git fetch origin next | ||
| done | ||
| [ -n "$conflict" ] || exit 1 |
There was a problem hiding this comment.
I'm not sure why we need to retry three times here?
Even if it's necessary, if the 3rd attempt fails, there is no way to alert ourselves of the failure. It just silently runs exit 1.
There was a problem hiding this comment.
The retry was for a PR merging into next between our fetch and our push, but you're right that running out of retries just failed quietly. I dropped the loop in 311122f: if the direct push fails for any reason, it now falls back to opening the "Merge dev into next" PR with the reason in the body, so it shows up where we already look.
| gh workflow run testing.yml --ref "$MERGE_BRANCH" | ||
| else | ||
| # The branch is dev itself, so the checks already run on dev apply. | ||
| git push --force origin "origin/dev:refs/heads/$MERGE_BRANCH" |
There was a problem hiding this comment.
An edge case, but this might be safer:
| git push --force origin "origin/dev:refs/heads/$MERGE_BRANCH" | |
| git push --force-with-lease origin "origin/dev:refs/heads/$MERGE_BRANCH" |
There was a problem hiding this comment.
Done in 311122f. I passed the expected SHA explicitly (--force-with-lease="$MERGE_BRANCH:$lease"), because the bare form can misfire when the branch doesn't exist yet. Tested that it rejects when someone pushes to the branch mid-run.
| github.event_name == 'push' && | ||
| (github.ref == 'refs/heads/master' || | ||
| github.ref == 'refs/heads/dev' || | ||
| startsWith(github.ref, 'refs/tags/')) |
There was a problem hiding this comment.
This is still restricted to master and dev - do we want to store build artifacts for pushes to next as well?
There was a problem hiding this comment.
Yes, RCs come from next, so we want those builds. Added in 311122f.
…h push, store next build artifacts
|
Sets up the
next+devworkflow from RFD #142 (Dash release management: a next branch alongside dev). Fixes and chores targetdevand ship as patches; features targetnextand ship as minors.Already done outside this PR:
nextcreated fromdevat 4.5.0 (00b8ed6), with a ruleset requiring a PR, one code-owner review, merge commits only, and the checksConsolidated Test Report,percy/dash-table-test,Forward merge not conflicted. Before merging: add the write deploy key, theDEV_NEXT_MERGE_KEYsecret, and the DeployKey bypass on thenextruleset.Changes
forward-merge.yml: on each push todev, mergesdevintonextand pushes it with theDEV_NEXT_MERGE_KEYdeploy key. The deploy key and admins are the only actors allowed to bypass thenextruleset. If the merge conflicts, it opens a "Merge dev into next" PR fromdev-into-nextinstead, and automatic merges pause until that PR is merged. It posts theForward merge not conflictedstatus on that PR itself, because PRs opened withGITHUB_TOKENdo not trigger workflows.branch-policy.yml:devthat add an UnreleasedAddedCHANGELOG entry.nextwhile the forward PR has conflicts.testing.yml: runs on push tonext;workflow_dispatchnow runs the full suite.CONTRIBUTING.md, the PR template andCLAUDE.mdexplain which branch to target and the release steps;.ai/PERFORMANCE.mdcovers per-branch benchmark baselines.Not verified yet
next/dev-into-nextmay need manual approval.Tested locally: the changelog script on fix, feature, old-style heading and existing-entry cases, and the forward-merge script against a local bare repo for each branch state (already merged, clean automatic merge, push race with another merge into
next, conflict opening a PR, new fixes while that PR is open, resolved branch with a clean or conflicting fix). Not tested in a running Dash app: no Dash runtime behavior changes.