[ci] Enable release-candidates and backport functionality - #841
Conversation
|
Warning Rate limit exceededAndrei Kvapil (@kvaps) has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 13 minutes and 0 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (4)
WalkthroughThis set of changes updates and enhances several GitHub Actions workflows. A new workflow for automatic backporting is introduced, which triggers on merged pull requests labeled "backport" and automates the creation of backport pull requests to the latest maintenance branch. The release and tag workflows are improved to handle release candidate tags, enforce stricter tag validation, perform semantic version comparisons, and manage release metadata and branches more robustly. The pull request workflow is updated to differentiate between internal and external contributors, adjusting label requirements accordingly, and simplifying build and test steps. Changes
Sequence Diagram(s)sequenceDiagram
participant PR as Pull Request
participant Backport Workflow
participant Repo
participant Backport Action
PR->>Backport Workflow: PR closed & merged with "backport" label
Backport Workflow->>Repo: Fetch latest release tag
Backport Workflow->>Repo: Determine maintenance branch (release-X.Y)
Backport Workflow->>Repo: Checkout code
Backport Workflow->>Backport Action: Create backport PR to maintenance branch
Backport Action->>Repo: Open backport PR
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
.github/workflows/tags.yaml (1)
85-85: Remove trailing spaces and extra spacing around colons
YAMLlint flagged trailing spaces at lines 85, 110, 248 and excessive spaces after colons at lines 133–134. Cleaning these up will satisfy lint checks and avoid CI warnings.Also applies to: 110-110, 133-134, 248-248
🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 85-85: too many spaces after colon
(colons)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/backport.yaml(1 hunks).github/workflows/pull-requests-release.yaml(1 hunks).github/workflows/pull-requests.yaml(2 hunks).github/workflows/tags.yaml(3 hunks)
🧰 Additional context used
🪛 actionlint (1.7.4)
.github/workflows/pull-requests-release.yaml
77-77: property "check_release" is not defined in object type {get_tag: {conclusion: string; outcome: string; outputs: object}}
(expression)
🪛 YAMLlint (1.35.1)
.github/workflows/tags.yaml
[warning] 85-85: too many spaces after colon
(colons)
[error] 110-110: trailing spaces
(trailing-spaces)
[warning] 133-133: too many spaces after colon
(colons)
[warning] 134-134: too many spaces after colon
(colons)
[error] 248-248: trailing spaces
(trailing-spaces)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Build and Test
🔇 Additional comments (25)
.github/workflows/pull-requests.yaml (3)
15-19: Clear CI execution comments
The new comments concisely explain the intent of the condition: internal PRs run automatically, forks need “ok-to-test”, and any PR with a “release” label is skipped. This enhances readability and maintainability.
21-28: Differentiate internal vs external contributors inifcondition
The updatedif:expression correctly allows runs for same‑repo PRs and gates forked PRs behind theok-to-testlabel, while always skipping onrelease. This aligns with best practices for contributor workflows.
44-49: Simplify build and test steps
Renaming the steps to “Build” and “Test” with single-linemakecommands improves clarity and reduces boilerplate..github/workflows/backport.yaml (4)
3-5: Usepull_request_targetto grant write permissions
Triggering onpull_request_targetis intentional here to allow the workflow to push backport PRs using the base‑repo’s token. Ensure this is documented and desired.Please confirm that exposing the workflow to
pull_request_targetdoes not conflict with any security policies for untrusted code.
13-16: Gate backport job on merge and label
Theif:condition correctly fires only when a PR is merged and labeledbackport. This prevents unintended runs and aligns with the PR objective.
34-37: Standard checkout for backport
Usingactions/checkout@v4without depth limits is correct to ensure the backport action can create branches and PRs.
38-44: Invoke backport-action with explicit target branch
Supplyingtarget_branchesfrom your computed output is the right approach. Settinglabel_pattern: ''avoids unintended label inheritances..github/workflows/pull-requests-release.yaml (4)
42-46: Restrict finalize job to merged “release” PRs
Theif:now ensures the finalize job only runs after a PR with thereleaselabel is merged. This prevents premature tagging and release operations.
55-63: Enhanced tag extraction supports suffixes
The regex/^release-(\d+\.\d+\.\d+(?:[-\w\.]+)?)$/now handles RC and other suffixes, improving flexibility for prereleases.
69-74: Force-update annotated tag on merge
Using-fforgit tagandgit pushguarantees that the tag points to the merge commit. This is appropriate for override scenarios.
118-139: Publish draft release with dynamic flags
Usingprereleaseandmake_latestparameters provides full control over the release metadata, supporting RC and legacy behaviors. The logging is clear and actionable..github/workflows/tags.yaml (14)
6-6: Support RC tags in workflow trigger
Changing the push filter tov*.*.*allows both standard and-rcNtags, enabling prerelease flows.
19-31: Check existing non-draft release before proceeding
Detecting if a release exists and skipping the rest of the workflow prevents duplicate publishes. The logic usingsome()is efficient.
38-58: Parse tag metadata for semantic versioning
Extractingtag,version,is_rc, andlinevia a single regex and outputs streamlines downstream steps.
69-76: Validate base branch origin
Ensuring tags are pushed frommainorrelease-X.Ywith clear failure messages guards against misdirected tag pushes.
85-88: Fetch full history and tags
Addingfetch-tags: trueensures annotations for existing tags are present in the runner, which is crucial for tag-based workflows.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 85-85: too many spaces after colon
(colons)
95-99: Build project artifacts before release
The consolidatedmake buildstep remains appropriately gated and clear.
101-109: Commit built artifacts with sign-off
Including-singit commitsigns off the actions bot, following DCO requirements and capturing attribution.
111-127: Retrieve latest published release for comparison
WrappinggetLatestReleasein atry/catchcaptures the absence of prior releases gracefully and outputs a blank tag for semver comparison.
128-135: Semver comparison determines “outdated” status
Usingmadhead/semver-utilsto compare the pushed tag against the latest published release is an effective way to drive “make_latest” logic.🧰 Tools
🪛 YAMLlint (1.35.1)
[warning] 133-133: too many spaces after colon
(colons)
[warning] 134-134: too many spaces after colon
(colons)
137-161: Create or reuse draft release dynamically
This block correctly handles idempotent draft release creation, settingprereleasefor RCs and a legacymake_latestflag for monolithic releases.
178-183: Ensure maintenance branch exists for new line
Auto-creatingrelease-X.Ywhen tagging frommainmaintains your maintenance workflow without manual intervention.
204-210: Force-update release branch to tag SHA
Creating and force-pushing therelease-X.Y.Zbranch guarantees consistency between the tag and the branch, simplifying backport and release PR flows.
212-219: Auto-generate release PR if missing
Checking for an existing PR and only creating one when absent prevents duplicate PR chatter and streamlines the release process.
247-251: Standardize final test step name
Renaming to “Test” for consistency with other workflows improves the uniformity of CI logs.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 248-248: trailing spaces
(trailing-spaces)
68401d4 to
5295a18
Compare
| on: | ||
| pull_request_target: | ||
| types: [closed] # fires when PR is closed (merged) |
There was a problem hiding this comment.
Why pull_request_target and not just pull_request? If we need the merge commit, we should probably use the latter
pull_request_target: This event runs in the context of the base of the pull request, rather than in the context of the merge commit, as the pull_request event does.
| on: | |
| pull_request_target: | |
| types: [closed] # fires when PR is closed (merged) | |
| on: | |
| pull_request_target: | |
| types: [closed] # fires when PR is closed (merged) |
There was a problem hiding this comment.
Oh, I see, it's what https://github.com/korthout/backport-action readme suggests.
| with: | ||
| github_token: ${{ secrets.GITHUB_TOKEN }} | ||
| label_pattern: '' # don't read labels for targets | ||
| target_branches: ${{ steps.target.outputs.branch }} |
There was a problem hiding this comment.
Pull request titles become commit titles, so let's make it shorter.
The default title was [Backport ${target_branch}] ${pull_title}
| target_branches: ${{ steps.target.outputs.branch }} | |
| target_branches: ${{ steps.target.outputs.branch }} | |
| pull_title: "[backport] ${pull_title}" |
There was a problem hiding this comment.
I think it is better to keep PR title as is, because the next step would be to enable backports to other branches as well
77a9adc to
c093477
Compare
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
c093477 to
63ebab5
Compare
|
Successfully created backport PR for |
Cherry-picking patches that came before #841 was merged. * Used `git cherry-pick -x -m1 <sha1>` on merge commits of respective pull requests. * Added `Co-authored-by` where the author of the changes was not the one who merged the PR (and authored the merge commit). Signed-off-by: Nick Volynkin <nick.volynkin@gmail.com>
This PR includes refactored pipeline:
release-X.Yafter any tagvX.Y.*has publushedvX.Y.ZorvX.Y.Z-rcNprereleaseoption for the release if release is candidatelatestoption for the release according to semverbackportlabel into current feature releaseok-to-testlabel for internal PRs