feat(ci): automate branch protection for release branches (LE-880)#12939
feat(ci): automate branch protection for release branches (LE-880)#12939
Conversation
- Add GitHub Action workflow to auto-detect release branch creation - Automatically apply standardized branch protection rules - Configure required status checks, PR reviews, and merge restrictions - Include comprehensive documentation for setup and troubleshooting - Implements workaround for wildcard pattern limitation with merge queues Resolves: LE-880
WalkthroughTwo new files establish automated branch protection for release branches. A documentation file describes the GitHub Actions workflow that applies branch protection rules to branches matching Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 9✅ Passed checks (9 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Review rate limit: 7/8 reviews remaining, refill in 7 minutes and 30 seconds.Comment |
github-actions
Bot
added
enhancement
Codecov Report✅ All modified and coverable lines are covered by tests. ❌ Your project check has failed because the head coverage (49.99%) is below the target coverage (60.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #12939 +/- ##
==========================================
+ Coverage 52.92% 52.93% +0.01%
==========================================
Files 2030 2030
Lines 183826 183826
Branches 27680 26202 -1478
==========================================
+ Hits 97286 97309 +23
+ Misses 85440 85418 -22
+ Partials 1100 1099 -1
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/setup-release-branch-protection.yml:
- Around line 122-138: The Post summary step currently always writes success
checkmarks because it runs with if: always(); change it so the step still runs
unconditionally but inspects the prior branch protection step's outcome (e.g.,
steps.apply_branch_protection.outcome or
steps.apply_branch_protection.conclusion) and emits either the success list or a
failure summary with clear error indicators; use the existing reference
steps.extract_branch.outputs.branch_name for the branch display and replace the
static checkmarks with conditional content based on that outcome so failures
produce a warning/error message instead of green checkmarks.
- Around line 3-6: The workflow uses an unsupported branches filter on the
create event: remove the branches key under the on.create block and keep just
"on: create"; then add a job-level guard to run only for release branches (e.g.
use an if conditional referencing github.ref or github.event.ref and
startsWith('refs/heads/release-') within the job) so the workflow only acts on
release-* branch creations; update any job names that expect this filter (job
identifiers) to include that if check.
- Around line 8-10: The workflow uses an invalid permissions key
"administration" and attempts to perform branch-protection updates with
GITHUB_TOKEN (see the permissions block and the updateBranchProtection API
calls), which will fail because GITHUB_TOKEN can't be elevated to repo admin;
replace the invalid key by removing "administration" from the permissions block
and change the workflow to read admin credentials from a new secret (e.g.
RELEASE_BRANCH_PROTECTION_TOKEN) that contains a GitHub App installation token
or PAT with repo admin rights, then use that token instead of GITHUB_TOKEN when
calling updateBranchProtection (and ensure the secret is added to the repository
secrets).
- Around line 43-51: The required_status_checks block currently lists contexts
like 'CI / Run Integration Tests' and 'CI / Lint Frontend' that are
path-filtered and can remain Pending when their workflows don't trigger; update
the branch protection config so only always-running checks are required or
change those workflows so they always run but perform path gating at the job
level (e.g., move path filters out of the workflow trigger into per-job
conditional execution while keeping the workflow triggered for every push/PR),
and remove or replace any path-filtered contexts from the contexts array (e.g.,
'CI / Run Integration Tests', 'CI / Lint Frontend') so branch protection never
depends on checks that can be skipped.
- Around line 72-110: The required_status_checks.contexts in the
updateBranchProtection call (see updateBranchProtection and
required_status_checks.contexts for branchName and merge_queue configuration)
list hardcoded check names that don't match the actual CI job names, causing
checks to never report as complete; update the contexts array in both branch
protection blocks to use the exact job names defined in .github/workflows/ci.yml
(e.g., "Run Backend Tests", "Run Frontend Unit Tests", "Run Frontend Tests",
etc.) or implement a mapping that translates the intended human-readable names
to those workflow job names so the merge_queue can correctly detect completed
checks.
🪄 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: CHILL
Plan: Pro
Run ID: c139b8a9-7ba5-40d7-bd38-fe484ed9fb22
📒 Files selected for processing (2)
.github/workflows/RELEASE_BRANCH_PROTECTION.md.github/workflows/setup-release-branch-protection.yml
| on: | ||
| create: | ||
| branches: | ||
| - 'release-*' |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions create event branches filter syntax documentation
💡 Result:
GitHub Actions does not support branch name filtering (branches / branches-ignore) on the workflow-level create event. So this syntax won’t work as an event filter: on: create: branches: - 'feature/' What to do instead 1) Use push with a branches filter, then gate “first-time branch creation” inside the workflow. - The create event runs when someone creates a Git reference (branch or tag). - But branch filtering is described for other triggers like push/pull_request, and the create trigger does not document/offer a branches filter. 2) Use an expression/condition to skip runs when the created ref doesn’t match your desired pattern. - The GitHub community guidance/workarounds recommend using an if condition based on github.ref (example uses contains(github.ref, 'refs/heads/releases/')). Example (skip at job level): on: create jobs: pr: if: ${{ startsWith(github.ref, 'refs/heads/feature/') }} runs-on: ubuntu-latest steps: - run: echo "Only runs for feature/*" Example (push-based approach): on: push: branches: - 'feature/' jobs: pr: # github.event.created is used as a signal for branch creation vs later pushes if: ${{ github.event.created && startsWith(github.ref, 'refs/heads/feature/') }} runs-on: ubuntu-latest steps: - run: echo "Runs on first creation (when created is true)" If you want the workflow not to even start, you can’t achieve that with a create-event branches filter; the filtering requires conditions (or switching to push + checking github.event.created).
Citations:
- 1: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 2: https://docs.github.com/actions/using-workflows/events-that-trigger-workflows
- 3: https://stackoverflow.com/questions/66819932/github-action-branch-creation-for-code-review-pull-request
- 4: https://github.community/t/trigger-job-on-branch-created/16878
🌐 Web query:
GitHub Actions workflow create event trigger reference
💡 Result:
The create event in GitHub Actions triggers a workflow when a Git branch or tag is created in the repository. It corresponds to the CreateEvent webhook. ### Trigger Configuration Use the on: create key in your workflow YAML: on: create No activity types are supported. Note: No event is created if more than three tags are created at once. GITHUB_SHA is the last commit on the created branch/tag. GITHUB_REF is the created branch or tag ref. ### Event Context Reference (github.event) The github.event object matches the CreateEvent webhook payload: | Property | Type | Description | |----------------|---------------|-------------| | ref | string | Git ref (branch name or tag name; null if ref_type is 'repository') | | ref_type | string | Type: 'branch', 'tag', or 'repository' | | master_branch | string | Repository's default branch (usually 'main') | | description | string/null | Repository's current description | | pusher_type | string | 'user' or deploy key | | full_ref | string | Fully-formed ref (e.g., 'refs/heads/branch-name') | Access via expressions like ${{ github.event.ref_type }} or ${{ github.event.ref }}. github.event_name is 'create'. For full webhook details, see GitHub's event types documentation. To inspect payloads, add a step: env: GITHUB_CONTEXT: ${{ toJSON(github) }}; run: echo "$GITHUB_CONTEXT". Official sources: GitHub Docs (Events that trigger workflows, Contexts reference, Webhook events and payloads, GitHub event types).
Citations:
- 1: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
- 2: https://docs.github.com/actions/using-workflows/events-that-trigger-workflows
- 3: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
- 4: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
- 5: https://docs.github.com/developers/webhooks-and-events/github-event-types
- 6: https://docs.github.com/en/actions/reference/contexts-reference
- 7: https://stackoverflow.com/questions/59349905/which-properties-does-github-event-in-a-github-workflow-have
- 8: https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=create
Remove the unsupported branches filter from create.
GitHub's create event does not accept branches filtering, so this workflow will not validate as written. The branches filter is only supported on events like push and pull_request. Use on: create unfiltered and apply a job-level condition if you need to differentiate release-branch creation.
Suggested fix
on:
- create:
- branches:
- - 'release-*'
+ create:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| on: | |
| create: | |
| branches: | |
| - 'release-*' | |
| on: | |
| create: |
🧰 Tools
🪛 actionlint (1.7.12)
[error] 5-5: "branches" filter is not available for create event. it is only for merge_group, push, pull_request, pull_request_target, workflow_run events
(events)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/setup-release-branch-protection.yml around lines 3 - 6,
The workflow uses an unsupported branches filter on the create event: remove the
branches key under the on.create block and keep just "on: create"; then add a
job-level guard to run only for release branches (e.g. use an if conditional
referencing github.ref or github.event.ref and startsWith('refs/heads/release-')
within the job) so the workflow only acts on release-* branch creations; update
any job names that expect this filter (job identifiers) to include that if
check.
| permissions: | ||
| contents: read | ||
| administration: write |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/setup-release-branch-protection.ymlRepository: langflow-ai/langflow
Length of output: 6615
🌐 Web query:
GitHub Actions workflow permissions valid keys documentation
💡 Result:
The valid keys for GitHub Actions workflow permissions are the scopes that control access for the GITHUB_TOKEN. These can be set at the workflow or job level using the 'permissions' key, with values 'read', 'write', or 'none' (write includes read). Unspecified permissions default to 'none'. Complete list of valid permission keys from official documentation: - actions: read|write|none - artifact-metadata: read|write|none - attestations: read|write|none - checks: read|write|none - contents: read|write|none - deployments: read|write|none - id-token: write|none - issues: read|write|none - models: read|none - discussions: read|write|none - packages: read|write|none - pages: read|write|none - pull-requests: read|write|none - security-events: read|write|none - statuses: read|write|none - vulnerability-alerts: read|none You can also use 'read-all' or 'write-all' for all permissions. Example usage: permissions: contents: read issues: write Official documentation: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
Citations:
- 1: https://docs.github.com/en/actions/reference/github_token-reference
- 2: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 3: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
🌐 Web query:
GitHub REST API updateBranchProtection permission requirements GITHUB_TOKEN
💡 Result:
To call the GitHub REST API to update branch protection (PUT /repos/{owner}/{repo}/branches/{branch}/protection), the authenticated actor must have admin or owner permissions to the repository. If you’re using GITHUB_TOKEN from GitHub Actions, that means the workflow’s token must be granted sufficient repository permissions via the workflow/job permissions settings; otherwise the API call will fail with an authorization error. GitHub documents that you can control the GITHUB_TOKEN’s permissions using the workflow file’s permissions key. Practical guidance (GitHub Actions): - Use a workflow/job permissions block to grant the needed GITHUB_TOKEN access. - If the needed permission isn’t available via GITHUB_TOKEN, GitHub’s docs recommend using a GitHub App installation token or a PAT instead. Endpoint: - PUT /repos/{owner}/{repo}/branches/{branch}/protection - Requirement stated by GitHub: “Protecting a branch requires admin or owner permissions to the repository.”
Citations:
- 1: https://docs.github.com/en/rest/branches/branch-protection
- 2: https://docs.github.com/actions/reference/authentication-in-a-workflow
- 3: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
- 4: https://docs.github.com/en/enterprise-server@3.16/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token
administration is not a valid permissions key, and GITHUB_TOKEN cannot satisfy branch-protection admin requirements.
The administration key does not exist in GitHub Actions workflow permissions. Valid keys are: actions, checks, contents, deployments, id-token, issues, packages, pages, pull-requests, security-events, statuses, and others—but there is no permission key that grants admin-level access to GITHUB_TOKEN.
The updateBranchProtection API endpoint requires admin or owner repository permissions. Since GITHUB_TOKEN cannot be elevated to admin level through the permissions block, this workflow will fail at runtime when attempting the API call on lines 39 and 74.
Use an admin-capable token instead—either a GitHub App installation token or a Personal Access Token with admin privileges:
Required fix
permissions:
contents: read
- administration: write
...
- github-token: ${{ secrets.GITHUB_TOKEN }}
+ github-token: ${{ secrets.RELEASE_BRANCH_PROTECTION_TOKEN }}Create RELEASE_BRANCH_PROTECTION_TOKEN as a repository secret containing a GitHub App or PAT with admin access.
🧰 Tools
🪛 actionlint (1.7.12)
[error] 10-10: unknown permission scope "administration". all available permission scopes are "actions", "artifact-metadata", "attestations", "checks", "contents", "deployments", "discussions", "id-token", "issues", "models", "packages", "pages", "pull-requests", "repository-projects", "security-events", "statuses"
(permissions)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/setup-release-branch-protection.yml around lines 8 - 10,
The workflow uses an invalid permissions key "administration" and attempts to
perform branch-protection updates with GITHUB_TOKEN (see the permissions block
and the updateBranchProtection API calls), which will fail because GITHUB_TOKEN
can't be elevated to repo admin; replace the invalid key by removing
"administration" from the permissions block and change the workflow to read
admin credentials from a new secret (e.g. RELEASE_BRANCH_PROTECTION_TOKEN) that
contains a GitHub App installation token or PAT with repo admin rights, then use
that token instead of GITHUB_TOKEN when calling updateBranchProtection (and
ensure the secret is added to the repository secrets).
| required_status_checks: { | ||
| strict: true, | ||
| contexts: [ | ||
| 'CI / Run Unit Tests', | ||
| 'CI / Run Integration Tests', | ||
| 'CI / Lint Backend', | ||
| 'CI / Lint Frontend', | ||
| 'CI / Type Check' | ||
| ] |
There was a problem hiding this comment.
Don't hard-require workflows that are path-filtered.
Some of the required checks (at least 'CI / Run Integration Tests' and 'CI / Lint Frontend') only run when their respective files change, as they're guarded by paths filters in their workflows. Per GitHub's documentation, skipped required checks remain in Pending status when their trigger conditions aren't met, which blocks merging. This means unrelated PRs (e.g., docs-only changes) can become unmergeable when these path-filtered checks don't run. Either require only checks that always run, or convert filtered workflows to always run but conditionally execute jobs (placing the path filter at the job level behind an always-reporting check).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/setup-release-branch-protection.yml around lines 43 - 51,
The required_status_checks block currently lists contexts like 'CI / Run
Integration Tests' and 'CI / Lint Frontend' that are path-filtered and can
remain Pending when their workflows don't trigger; update the branch protection
config so only always-running checks are required or change those workflows so
they always run but perform path gating at the job level (e.g., move path
filters out of the workflow trigger into per-job conditional execution while
keeping the workflow triggered for every push/PR), and remove or replace any
path-filtered contexts from the contexts array (e.g., 'CI / Run Integration
Tests', 'CI / Lint Frontend') so branch protection never depends on checks that
can be skipped.
| // Enable merge queue if available | ||
| try { | ||
| await github.rest.repos.updateBranchProtection({ | ||
| owner, | ||
| repo, | ||
| branch: branchName, | ||
| required_status_checks: { | ||
| strict: true, | ||
| contexts: [ | ||
| 'CI / Run Unit Tests', | ||
| 'CI / Run Integration Tests', | ||
| 'CI / Lint Backend', | ||
| 'CI / Lint Frontend', | ||
| 'CI / Type Check' | ||
| ] | ||
| }, | ||
| enforce_admins: false, | ||
| required_pull_request_reviews: { | ||
| dismiss_stale_reviews: true, | ||
| require_code_owner_reviews: true, | ||
| required_approving_review_count: 2, | ||
| require_last_push_approval: true | ||
| }, | ||
| restrictions: null, | ||
| required_linear_history: false, | ||
| allow_force_pushes: false, | ||
| allow_deletions: false, | ||
| block_creations: false, | ||
| required_conversation_resolution: true, | ||
| lock_branch: false, | ||
| allow_fork_syncing: false, | ||
| // Merge queue configuration | ||
| merge_queue: { | ||
| enabled: true, | ||
| merge_method: 'squash', | ||
| check_response_timeout_minutes: 60, | ||
| grouping_strategy: 'ALLGREEN' | ||
| } | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find .github/workflows -type f -name "*.yml" -o -name "*.yaml" | head -20Repository: langflow-ai/langflow
Length of output: 779
🏁 Script executed:
cat .github/workflows/setup-release-branch-protection.yml 2>/dev/null | head -150Repository: langflow-ai/langflow
Length of output: 5635
🏁 Script executed:
# Find all workflow files
git ls-files .github/workflows/ | grep -E '\.(yml|yaml)$'Repository: langflow-ai/langflow
Length of output: 1466
🏁 Script executed:
cat .github/workflows/ci.yml | head -100Repository: langflow-ai/langflow
Length of output: 2879
🏁 Script executed:
# Search for merge_group in all workflows
rg "merge_group" .github/workflows/Repository: langflow-ai/langflow
Length of output: 1420
🏁 Script executed:
# Check for the check names in ci.yml
rg "Run Unit Tests|Run Integration Tests|Lint Backend|Lint Frontend|Type Check" .github/workflows/ci.yml -A 5 -B 5Repository: langflow-ai/langflow
Length of output: 46
🏁 Script executed:
rg "name:" .github/workflows/ci.yml | grep -E "job|name:" | head -30Repository: langflow-ai/langflow
Length of output: 1022
🏁 Script executed:
# Look for job definitions and their names
ast-grep --pattern 'jobs:
$$$' .github/workflows/ci.yml 2>/dev/null || cat .github/workflows/ci.yml | grep -A 200 "^jobs:" | head -100Repository: langflow-ai/langflow
Length of output: 30562
🏁 Script executed:
# Check other workflow files that might provide the required checks
cat .github/workflows/integration_tests.yml | head -80Repository: langflow-ai/langflow
Length of output: 1598
🏁 Script executed:
# Search for the exact check names in all workflows
rg "CI / Run Unit Tests|CI / Run Integration Tests|CI / Lint Backend|CI / Lint Frontend|CI / Type Check" .github/workflows/Repository: langflow-ai/langflow
Length of output: 1548
🏁 Script executed:
# Check the python_test.yml reusable workflow
cat .github/workflows/python_test.yml | head -80Repository: langflow-ai/langflow
Length of output: 2491
🏁 Script executed:
# Check the jest_test.yml reusable workflow
cat .github/workflows/jest_test.yml | head -80Repository: langflow-ai/langflow
Length of output: 2186
🏁 Script executed:
# Look for any workflow that might generate these specific check names
rg "Run Unit Tests|Run Integration Tests|Lint Backend|Lint Frontend|Type Check" .github/workflows/ --type yaml -B 3 -A 3Repository: langflow-ai/langflow
Length of output: 2713
🏁 Script executed:
# Check if there are GitHub composite actions or other mechanisms generating these names
find .github -name "*.yml" -o -name "*.yaml" | xargs grep -l "outputs\|run:" | head -20Repository: langflow-ai/langflow
Length of output: 766
🏁 Script executed:
# Look for any lint workflows
ls -la .github/workflows/ | grep -i lintRepository: langflow-ai/langflow
Length of output: 188
🏁 Script executed:
# Check the lint-py and lint-js workflows
cat .github/workflows/lint-py.yml 2>/dev/null | head -60Repository: langflow-ai/langflow
Length of output: 1122
🏁 Script executed:
cat .github/workflows/lint-js.ymlRepository: langflow-ai/langflow
Length of output: 1238
🏁 Script executed:
# Search for where "CI /" prefix is added to check names
rg "CI /" .github/workflows/ --type yamlRepository: langflow-ai/langflow
Length of output: 1042
🏁 Script executed:
# Check if there's a documentation about the expected check names
cat .github/workflows/RELEASE_BRANCH_PROTECTION.md 2>/dev/nullRepository: langflow-ai/langflow
Length of output: 5071
🏁 Script executed:
# Verify what the actual check/job names are in ci.yml when it runs
# Look for where jobs generate their check names
cat .github/workflows/python_test.yml | grep -A 5 "name:"Repository: langflow-ai/langflow
Length of output: 6202
🏁 Script executed:
# Check if ci.yml is calling these workflows with specific outputs
cat .github/workflows/ci.yml | grep -A 20 "uses: ./.github/workflows/"Repository: langflow-ai/langflow
Length of output: 3476
🏁 Script executed:
# Check if lint-py.yml and lint-js.yml have merge_group trigger
cat .github/workflows/lint-py.yml | grep -E "^on:|merge_group|pull_request|workflow"Repository: langflow-ai/langflow
Length of output: 106
🏁 Script executed:
cat .github/workflows/lint-js.yml | grep -E "^on:|merge_group|pull_request|workflow"Repository: langflow-ai/langflow
Length of output: 106
🏁 Script executed:
# Also check typescript_test.yml which is used for frontend tests
cat .github/workflows/typescript_test.yml | head -50Repository: langflow-ai/langflow
Length of output: 1288
🏁 Script executed:
# Search for any configuration that adds the "CI / " prefix to check names
rg "CI /" . --type yaml --type json 2>/dev/null | grep -v "setup-release-branch-protection" | grep -v "RELEASE_BRANCH_PROTECTION.md"Repository: langflow-ai/langflow
Length of output: 46
🏁 Script executed:
# Check if there's any action or script that maps job names to check names
find .github -type f \( -name "*.yml" -o -name "*.yaml" -o -name "*.js" -o -name "*.py" \) | xargs grep -l "check.*name\|status.*check" 2>/dev/null | head -10Repository: langflow-ai/langflow
Length of output: 175
🏁 Script executed:
# Look at the ci.yml job definitions more carefully - check if there's a top-level job that aggregates/names these
cat .github/workflows/ci.yml | grep -A 5 "jobs:" | head -20Repository: langflow-ai/langflow
Length of output: 392
🏁 Script executed:
# Let me check if ci.yml has any special naming for its top-level jobs
cat .github/workflows/ci.yml | grep -E "^\s+name:" | head -20Repository: langflow-ai/langflow
Length of output: 461
🏁 Script executed:
# Check the structure - what are the actual job names that would be reported as checks?
cat .github/workflows/ci.yml | grep -B 2 "name:" | grep -E "^\s+test-|^\s+ci_" | head -20Repository: langflow-ai/langflow
Length of output: 166
🏁 Script executed:
# Let's see the full job structure with names
cat .github/workflows/ci.yml | grep -E "^ [a-z-]+:" | head -20Repository: langflow-ai/langflow
Length of output: 349
The required status check names do not match the actual CI job names in the workflow.
The hardcoded required checks ('CI / Run Unit Tests', 'CI / Run Integration Tests', 'CI / Lint Backend', 'CI / Lint Frontend', 'CI / Type Check') will never complete because the actual CI workflow jobs are named differently ("Run Backend Tests", "Run Frontend Unit Tests", "Run Frontend Tests", etc.). When merge queue attempts to verify the required checks, they will never report as complete, causing PRs to stall in the queue.
Update the required_status_checks.contexts array in both branch protection configuration blocks to match the actual job names from .github/workflows/ci.yml, or ensure a mapping exists between the intended check names and the workflow job names.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/setup-release-branch-protection.yml around lines 72 - 110,
The required_status_checks.contexts in the updateBranchProtection call (see
updateBranchProtection and required_status_checks.contexts for branchName and
merge_queue configuration) list hardcoded check names that don't match the
actual CI job names, causing checks to never report as complete; update the
contexts array in both branch protection blocks to use the exact job names
defined in .github/workflows/ci.yml (e.g., "Run Backend Tests", "Run Frontend
Unit Tests", "Run Frontend Tests", etc.) or implement a mapping that translates
the intended human-readable names to those workflow job names so the merge_queue
can correctly detect completed checks.
| - name: Post summary | ||
| if: always() | ||
| run: | | ||
| echo "## Branch Protection Setup" >> $GITHUB_STEP_SUMMARY | ||
| echo "" >> $GITHUB_STEP_SUMMARY | ||
| echo "**Branch:** \`${{ steps.extract_branch.outputs.branch_name }}\`" >> $GITHUB_STEP_SUMMARY | ||
| echo "" >> $GITHUB_STEP_SUMMARY | ||
| echo "### Protection Rules Applied:" >> $GITHUB_STEP_SUMMARY | ||
| echo "- ✅ Required status checks enabled" >> $GITHUB_STEP_SUMMARY | ||
| echo "- ✅ Required pull request reviews (2 approvals)" >> $GITHUB_STEP_SUMMARY | ||
| echo "- ✅ Code owner reviews required" >> $GITHUB_STEP_SUMMARY | ||
| echo "- ✅ Dismiss stale reviews enabled" >> $GITHUB_STEP_SUMMARY | ||
| echo "- ✅ Require last push approval" >> $GITHUB_STEP_SUMMARY | ||
| echo "- ✅ Conversation resolution required" >> $GITHUB_STEP_SUMMARY | ||
| echo "- ✅ Force pushes blocked" >> $GITHUB_STEP_SUMMARY | ||
| echo "- ✅ Branch deletion blocked" >> $GITHUB_STEP_SUMMARY | ||
| echo "- ⚠️ Merge queue (if supported by repository)" >> $GITHUB_STEP_SUMMARY |
There was a problem hiding this comment.
The summary reports success even when setup fails.
Post summary runs under always() and always writes green checkmarks, even when the API step fails. That leaves a failed run with a success-looking summary for a repo-security control. Drive this section from the previous step outcome and emit a failure summary when setup does not complete.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/setup-release-branch-protection.yml around lines 122 -
138, The Post summary step currently always writes success checkmarks because it
runs with if: always(); change it so the step still runs unconditionally but
inspects the prior branch protection step's outcome (e.g.,
steps.apply_branch_protection.outcome or
steps.apply_branch_protection.conclusion) and emits either the success list or a
failure summary with clear error indicators; use the existing reference
steps.extract_branch.outputs.branch_name for the branch display and replace the
static checkmarks with conditional content based on that outcome so failures
produce a warning/error message instead of green checkmarks.
Frontend Unit Test Coverage ReportCoverage Summary
Unit Test Results
|
1 participant
Summary
Implements automated branch protection rule setup for release branches to address GitHub's limitation where wildcard patterns (
release-*) don't work with merge queues enabled.Changes
release-*branch creationHow It Works
release-1.11.0)Branch Protection Rules Applied
Testing
release-test-1.0.0branch before production useDocumentation
See
.github/workflows/RELEASE_BRANCH_PROTECTION.mdfor complete documentation, troubleshooting, and maintenance instructions.Related
Summary by CodeRabbit
Chores
Documentation