ci: add automatic backport workflow#24025
Conversation
matifali
left a comment
There was a problem hiding this comment.
Anything to block cherry-picks that contain invalid DB migrations? I think it is blocked during the release process.
coder/.github/workflows/release.yaml
Line 242 in 333503f
|
Clean direction overall. Automating the last three release backports behind a label is useful, and the docs make the intended workflow easy to follow. I found one correctness issue that I think needs attention before merge, plus one operational concern in the same area.
|
|
P1 conflicted cherry-picks can produce a broken backport branch After
Nit the docs overstate the conflict behavior The docs say the backport PR is still created "with conflict markers so you can resolve them manually." That matches the current script, but it is also the risky part of the implementation. If the workflow changes to fail cleanly or create a manual-follow-up path instead, this text should move with it.
|
There was a problem hiding this comment.
There's already a script that backports a merged PR to a release branch: https://github.com/coder/coder/blob/61d6c728b9b3618d1e4ac212c254455e4387b376/scripts/backport-pr.sh
Should we invoke the script for the last N release branches in this action? This script is also a bit more comprehensive, I think. It adds the release cherry-pick label, opens the PR as a draft first, among other things.
|
|
||
| # Check if a PR already exists for this branch (idempotency | ||
| # for re-runs). | ||
| EXISTING_PR=$(gh pr list --head "$BACKPORT_BRANCH" --base "$RELEASE_VERSION" --json number --jq '.[0].number // empty') |
There was a problem hiding this comment.
gh pr list will only find PRs that are open by default https://cli.github.com/manual/gh_pr_list
I think we would want --state all for idempotency
There was a problem hiding this comment.
Good catch — fixed in c333e4e. Added --state all so closed/merged backport PRs are also detected.
Generated with Coder Agents
| @@ -0,0 +1,174 @@ | |||
| # Automatically backport merged PRs to the last N release branches when the | |||
There was a problem hiding this comment.
Thoughts on leveraging the existing cherry-pick/v* labels instead of always backporting to the last 3 versions? I don't know if choosing the last 3 always solves. Maybe the last 3 is easiest for now?
There was a problem hiding this comment.
I just saw https://redirect.github.com/coder/coder/pull/24051 😄 , so you can probably disregard this comment
|
Both points addressed: P1 (conflict handling): The workflow now aborts the failed cherry-pick and creates an empty commit with manual resolution instructions instead of force-continuing with conflict markers. The PR is still opened so the author has a clear place to push the manual fix, but no broken code is committed. Nit (docs): Updated to say "with instructions for manual resolution — no conflict markers are committed" which matches the current behavior. Note Generated with Coder Agents |
Adds a GitHub Actions workflow that cherry-picks merged PRs to the latest release branch when the `cherry-pick` label is applied. ## How it works 1. Add the `cherry-pick` label to any PR targeting `main` (before or after merge). 2. On merge (or on label if already merged), the workflow detects the latest `release/*` branch. 3. It cherry-picks the merge commit (`-x -m1`) and opens a PR. This complements the `backport` label (see #24025) which targets the latest **3** release branches. `cherry-pick` targets only the **latest** one — useful for getting fixes into the current release. Created PRs follow existing repo conventions: - **Branch:** `backport/<pr>-to-<version>` - **Title:** `<original PR title> (#<pr>)` — e.g. `fix(site): correct button alignment (#12345)` - **Body:** links back to the original PR and merge commit If the cherry-pick encounters conflicts, the workflow aborts the cherry-pick, creates an empty commit with resolution instructions, and opens the PR with a `[CONFLICT]` prefix so the author can resolve manually. Also: - Removes `scripts/backport-pr.sh` (replaced by this workflow) - Removes `.github/cherry-pick-bot.yml` (old bot config) - Adds a section to the contributing docs explaining the `cherry-pick` label > [!NOTE] > Generated with [Coder Agents](https://coder.com/agents)
Adds a GitHub Actions workflow that automatically cherry-picks merged PRs to the last 3 release branches when the 'backport' label is applied. The label can be added before or after the PR is merged. The workflow detects the latest release/* branches by semver, cherry-picks the merge commit, and opens draft PRs following existing repo conventions (branch naming, labels, title format).
- Replace conflict-marker commits with cherry-pick --abort + empty commit explaining the situation. This avoids pushing broken code to backport branches. - On conflict, append '(conflicts)' to PR title and add a warning block with manual resolution instructions. - Add idempotency guards: skip if the backport branch already exists remotely, and skip gh pr create if a PR already exists. This makes workflow re-runs safe.
gh pr list only finds open PRs by default. If a backport PR was previously opened and then closed, a re-run would create a duplicate. Using --state all catches open, closed, and merged PRs.
c333e4e to
9479800
Compare
Adds a GitHub Actions workflow that automatically cherry-picks merged PRs to the last 3 release branches when the
backportlabel is applied.How it works
backportlabel to any PR targetingmain(before or after merge).release/*branches by semver.-x -m1) and opens a PR.Created backport PRs follow existing repo conventions:
backport/<pr>-to-<version><original PR title> (#<pr>)— e.g.fix(site): correct button alignment (#12345)If cherry-pick has conflicts, the PR is still opened with instructions for manual resolution — no conflict markers are committed.
Also:
scripts/backport-pr.sh(replaced by this workflow).github/cherry-pick-bot.yml(old bot config)Note
Generated with Coder Agents