ci: GitHub Pages deploy pipeline - preview, staging and production#20
Merged
Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughWalkthroughThree GitHub Actions workflows are added to establish a complete deployment pipeline: a PR preview workflow that builds and publishes per-PR Flutter web deployments to ChangesFlutter Web Deployment Workflows
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
hiranyasemindi
approved these changes
Jun 17, 2026
Contributor
Preview deployed
Updates automatically on every push. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (2)
.github/workflows/deploy-preview.yml (2)
25-25: ⚡ Quick winAdd
persist-credentials: falseto harden checkout security.The
checkoutaction persists the GitHub token in.git/configby default, which could be exploited if malicious code runs in subsequent steps. Since thepeaceiris/actions-gh-pagesaction receives its owngithub_tokenparameter (line 41) and doesn't rely on the persisted credentials, settingpersist-credentials: falsefollows defense-in-depth principles without breaking functionality.🔒 Proposed security hardening
steps: - uses: actions/checkout@v4 + with: + persist-credentials: false - uses: subosito/flutter-action@v2🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-preview.yml at line 25, The `actions/checkout@v4` action currently persists the GitHub token in `.git/config` by default, creating a security risk if malicious code executes in subsequent workflow steps. Add the `persist-credentials: false` parameter to the checkout action configuration to disable this behavior. Since the `peaceiris/actions-gh-pages` action on line 41 provides its own `github_token` parameter, this change will harden security without affecting the workflow's functionality.Source: Linters/SAST tools
7-9: ⚡ Quick winConsider scoping permissions per job for least-privilege security.
Currently, both
contents: writeandpull-requests: writeare granted at the workflow level, but only thedeployjob needs both permissions—thecleanupjob requires onlycontents: write. Scoping permissions per job reduces the attack surface.🔒 Proposed refactor to scope permissions per job
Remove the workflow-level permissions and scope them per job:
-permissions: - contents: write - pull-requests: write - concurrency: group: pr-preview-${{ github.event.number }} cancel-in-progress: true jobs: deploy: if: github.event.action != 'closed' name: Deploy preview runs-on: ubuntu-latest + permissions: + contents: write + pull-requests: write environment: name: pr-preview-${{ github.event.number }} url: https://getbms.github.io/bms/pr-${{ github.event.number }}/And for the cleanup job:
cleanup: if: github.event.action == 'closed' name: Remove preview runs-on: ubuntu-latest + permissions: + contents: write steps:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-preview.yml around lines 7 - 9, Remove the workflow-level permissions block from the top of the workflow file and instead add job-specific permissions. For the deploy job, add permissions with contents: write and pull-requests: write, and for the cleanup job, add permissions with only contents: write. This follows the principle of least privilege by ensuring each job only receives the permissions it actually requires for its operations.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/deploy-prod.yml:
- Around line 32-35: The actions/checkout@v4 action is persisting Git
credentials by default, which unnecessarily exposes the GITHUB_TOKEN. Add a new
line to the with section of the actions/checkout@v4 action to set
persist-credentials: false, ensuring that Git credentials are not persisted to
.git/config since the deployment step provides an explicit token and no
subsequent steps require persisted credentials.
- Line 32: The actions/checkout@v4 action is using a floating tag which poses a
security risk. Replace the floating tag `@v4` with the full commit SHA of that
release to pin the action to an immutable version. Visit the actions/checkout
repository releases page on GitHub, find the commit SHA associated with the v4
tag, and update the action reference from actions/checkout@v4 to
actions/checkout@<full-commit-sha> using the exact SHA provided by GitHub.
In @.github/workflows/deploy-staging.yml:
- Line 53: The commit_message field currently uses ${{ github.sha }} which may
not match the actual deployed commit when the workflow is manually triggered
with a custom ref parameter. Instead, capture the actual HEAD SHA of the
checked-out repository (typically available as an output from the checkout step
or by running a git command to get the current HEAD SHA) and replace the ${{
github.sha }} reference in the commit_message with this captured actual SHA
value to ensure the staging commit metadata reflects the true deployed commit.
- Line 31: The GitHub Actions in the workflow file are pinned to mutable version
tags (actions/checkout@v4) which creates a supply chain security risk. Replace
all instances of mutable version tag references (including actions/checkout@v4
at line 31 and the similar references at lines 35 and 47) with their full commit
SHA hashes to make the action references immutable. Determine the correct commit
SHA for each action version and update the uses directive accordingly to
eliminate the vulnerability.
- Around line 31-33: The actions/checkout@v4 step is persisting credentials by
default, which makes the GITHUB_TOKEN available to all subsequent workflow steps
unnecessarily. Add persist-credentials: false to the with section of the
actions/checkout@v4 step to disable credential persistence. This hardens the
workflow by ensuring that the GitHub token is only available where explicitly
needed, specifically in the publish step that receives github_token directly.
---
Nitpick comments:
In @.github/workflows/deploy-preview.yml:
- Line 25: The `actions/checkout@v4` action currently persists the GitHub token
in `.git/config` by default, creating a security risk if malicious code executes
in subsequent workflow steps. Add the `persist-credentials: false` parameter to
the checkout action configuration to disable this behavior. Since the
`peaceiris/actions-gh-pages` action on line 41 provides its own `github_token`
parameter, this change will harden security without affecting the workflow's
functionality.
- Around line 7-9: Remove the workflow-level permissions block from the top of
the workflow file and instead add job-specific permissions. For the deploy job,
add permissions with contents: write and pull-requests: write, and for the
cleanup job, add permissions with only contents: write. This follows the
principle of least privilege by ensuring each job only receives the permissions
it actually requires for its operations.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 209da4a6-e725-4eae-ab16-7d07f198ef58
📒 Files selected for processing (3)
.github/workflows/deploy-preview.yml.github/workflows/deploy-prod.yml.github/workflows/deploy-staging.yml
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
- Pin all action references to immutable commit SHAs - Add persist-credentials: false to all checkout steps - Fix staging commit_message to use actual HEAD SHA after checkout - Move deploy-preview permissions to job level (least privilege)
hiranyasemindi
approved these changes
Jun 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Sets up a full GitHub Pages deployment pipeline with three environments: PR preview, staging, and production.
Type
Changes
deploy-preview.yml- triggers on every PR commit, deploys to/bms/pr-{N}/, posts a live URL comment on the PR, cleans up the preview directory when the PR is closeddeploy-staging.yml- triggers automatically when a PR merges to master, deploys to/bms/staging/, also has a manualworkflow_dispatchfallbackdeploy-prod.yml- triggers automatically when staging completes successfully, deploys to/bms/(root), also has a manualworkflow_dispatchfallbackPipeline flow:
All three environments are configured in GitHub Settings > Environments (staging has 1 protection rule already set).
Test plan
Related issues
Closes - GitHub Pages deployment setup
Summary by CodeRabbit
Summary by CodeRabbit