ci: deploy manually to canary env from main#2627
Conversation
Instead of using "branch tracking" on the canary Vercel env, this triggers a deploy from GitHub Actions on pushes to the `main` branch in this repo.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
|
Important Review skippedAuto reviews are limited based on label configuration. 🚫 Review skipped — only excluded labels are configured. (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds a new GitHub Actions workflow that triggers on pushes to Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant GH as GitHub
participant Runner as Actions Runner
participant Vercel as Vercel API
Dev->>GH: push to main
GH->>Runner: trigger deploy-canary workflow
Runner->>GH: checkout repository
Runner->>Runner: setup Node (voidzero-dev/setup-vp), install vercel CLI
Runner->>Vercel: run `npx vercel deploy --target=canary` (uses VERCEL_TOKEN, VERCEL_ORG_ID, VERCEL_PROJECT_ID)
Vercel-->>Runner: deployment status
Runner-->>GH: report workflow status
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 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. Comment |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
.github/workflows/deploy-canary.yml (3)
11-13:fetch-depth: 0is likely unnecessary here.A full clone is only needed when the build/deploy uses git history (e.g. changelog generation,
git describe). A plainvercel deploydoes not. Dropping it speeds up checkout and reduces transfer/cache size; if some downstream tool actually needs history, please ignore.♻️ Proposed change
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 - with: - fetch-depth: 0🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy-canary.yml around lines 11 - 13, The workflow currently forces a full git clone by setting fetch-depth: 0 on the actions/checkout step; remove the fetch-depth: 0 (or set fetch-depth: 1) in the checkout action (the actions/checkout@... usage) so the job performs a shallow clone and speeds up checkout unless some downstream step explicitly requires full history (keep the checkout step unchanged except for removing/changing the fetch-depth key).
5-9: Set least-privilegepermissions:forGITHUB_TOKEN.This workflow does not need to write to the repo; the deploy is authenticated via
VERCEL_TOKEN. Adding an explicitpermissions:block (defaulting tocontents: read) follows GitHub's hardening guidance and is a no-op for current behaviour.🛡️ Proposed addition
jobs: deploy-canary: if: github.repository == 'npmx-dev/npmx.dev' name: 🚀 Deploy to canary (main.npmx.dev) runs-on: ubuntu-24.04-arm + permissions: + contents: read steps:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy-canary.yml around lines 5 - 9, Add an explicit least-privilege permissions block to the deploy-canary job so the GITHUB_TOKEN is only granted read access (e.g., permissions: contents: read); update the job named "deploy-canary" (the deploy-canary job block) to include that permissions stanza at the job level so it does not grant write access unnecessarily while leaving authentication via VERCEL_TOKEN untouched.
1-1: Add a top-levelname:for the workflow.Helps it show up clearly in the Actions UI, status checks, and
gh workflowlistings. Minor nit.📝 Proposed addition
+name: Deploy canary on: push: branches: [main]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy-canary.yml at line 1, Add a top-level "name:" field to the workflow so it appears clearly in Actions UI and gh workflow listings; update the YAML that currently starts with "on:" to instead include a top-level "name: <descriptive name>" above the existing "on:" key (keep the existing "on:" configuration intact).
🤖 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/deploy-canary.yml:
- Around line 5-16: The deploy-canary job is missing a concurrency policy
causing parallel canary deploy races; add a concurrency block to the
deploy-canary job (the job named "🚀 Deploy to canary (main.npmx.dev)" with id
deploy-canary) that sets a branch-scoped group (e.g. "canary-${{ github.ref }}"
or similar) and set cancel-in-progress: true if you only want the latest commit
to deploy (or false to let all finish), ensuring only one vercel deploy
--target=canary runs for a given branch at a time.
- Around line 14-16: Update the deploy step that runs "npx vercel deploy
--target=canary" to add the missing CI env vars VERCEL_ORG_ID and
VERCEL_PROJECT_ID (set from secrets VERCEL_ORG_ID and VERCEL_PROJECT_ID) so the
Vercel CLI has project context, remove the redundant explicit --token flag since
VERCEL_TOKEN in env is picked up automatically, and pin or explicitly request
the CLI version (e.g. use npx vercel@latest or a specific version) to avoid
silent behavior changes; ensure you reference the existing VERCEL_TOKEN env
variable and the deploy command ("npx vercel deploy --target=canary") when
making these changes.
---
Nitpick comments:
In @.github/workflows/deploy-canary.yml:
- Around line 11-13: The workflow currently forces a full git clone by setting
fetch-depth: 0 on the actions/checkout step; remove the fetch-depth: 0 (or set
fetch-depth: 1) in the checkout action (the actions/checkout@... usage) so the
job performs a shallow clone and speeds up checkout unless some downstream step
explicitly requires full history (keep the checkout step unchanged except for
removing/changing the fetch-depth key).
- Around line 5-9: Add an explicit least-privilege permissions block to the
deploy-canary job so the GITHUB_TOKEN is only granted read access (e.g.,
permissions: contents: read); update the job named "deploy-canary" (the
deploy-canary job block) to include that permissions stanza at the job level so
it does not grant write access unnecessarily while leaving authentication via
VERCEL_TOKEN untouched.
- Line 1: Add a top-level "name:" field to the workflow so it appears clearly in
Actions UI and gh workflow listings; update the YAML that currently starts with
"on:" to instead include a top-level "name: <descriptive name>" above the
existing "on:" key (keep the existing "on:" configuration intact).
🪄 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: 8f301844-609c-4367-91a7-36af7db50220
📒 Files selected for processing (1)
.github/workflows/deploy-canary.yml
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…ntain permissions' Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/workflows/deploy-canary.yml (2)
14-16:fetch-depth: 0is likely unnecessary for a remote Vercel deploy.
vercel deploy(without--prebuilt) uploads the working tree and builds remotely; it does not need git history.fetch-depth: 0clones the full history, which adds avoidable I/O and wall-clock time on every push tomain. Unless something downstream (e.g. a build step, changelog generation) needs full history, drop it and use the default shallow clone.🔧 Proposed change
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 - with: - fetch-depth: 0🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy-canary.yml around lines 14 - 16, The workflow uses actions/checkout with fetch-depth: 0 which clones full git history unnecessarily for a remote Vercel deploy; update the actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd usage by removing the fetch-depth: 0 option (or set it to the default shallow value) so the runner performs a shallow clone and avoids extra I/O and time; look for the actions/checkout step in the CI job and remove or change the fetch-depth key accordingly.
1-19: Consider adding a top-level workflowname.Without a top-level
name:, GitHub falls back to the file path in the Actions UI and in status checks. A short explicit name (e.g.name: Deploy canary) makes the workflow easier to identify alongside the other workflows in this repo.🔧 Proposed addition
+name: Deploy canary + on: push: branches: [main]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy-canary.yml around lines 1 - 19, Add a top-level workflow name so Actions UI and status checks show a clear label instead of the file path; insert a single line like name: "Deploy canary" immediately before the existing on: block in the workflow file that defines the deploy-canary job (the block containing on:, permissions:, and jobs: with the deploy-canary job name and runs-on), ensuring the identifier is short and descriptive.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/deploy-canary.yml:
- Around line 14-16: The workflow uses actions/checkout with fetch-depth: 0
which clones full git history unnecessarily for a remote Vercel deploy; update
the actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd usage by removing
the fetch-depth: 0 option (or set it to the default shallow value) so the runner
performs a shallow clone and avoids extra I/O and time; look for the
actions/checkout step in the CI job and remove or change the fetch-depth key
accordingly.
- Around line 1-19: Add a top-level workflow name so Actions UI and status
checks show a clear label instead of the file path; insert a single line like
name: "Deploy canary" immediately before the existing on: block in the workflow
file that defines the deploy-canary job (the block containing on:, permissions:,
and jobs: with the deploy-canary job name and runs-on), ensuring the identifier
is short and descriptive.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 980e666d-0bf1-4722-a0ff-18a7a76b81f2
📒 Files selected for processing (1)
.github/workflows/deploy-canary.yml
Added concurrency settings for canary deployment.
Removed fetch-depth option from checkout step.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/deploy-canary.yml (1)
13-19: Optional: add a job-leveltimeout-minutes.Without an explicit timeout, a hung
vercel deploy(e.g. CLI auth/network stall) will sit on the default 360-minute job timeout and burn Actions minutes. A modest cap (e.g. 15–20 min) gives a fast, predictable failure for canary deploys.♻️ Proposed change
deploy-canary: if: github.repository == 'npmx-dev/npmx.dev' name: 🚀 Deploy to canary (main.npmx.dev) runs-on: ubuntu-24.04-arm + timeout-minutes: 20 steps:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy-canary.yml around lines 13 - 19, Add a job-level timeout to the deploy-canary job to avoid long-running hung deploys: update the job block named deploy-canary and add a timeout-minutes key (e.g., timeout-minutes: 20) at the same indentation as name/runs-on/steps so the GitHub Actions runner will cancel the job after the specified minutes if vercel deploy stalls.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/deploy-canary.yml:
- Around line 13-19: Add a job-level timeout to the deploy-canary job to avoid
long-running hung deploys: update the job block named deploy-canary and add a
timeout-minutes key (e.g., timeout-minutes: 20) at the same indentation as
name/runs-on/steps so the GitHub Actions runner will cancel the job after the
specified minutes if vercel deploy stalls.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: ab5a41b8-1adf-4e60-870c-3d5dabc45b8a
📒 Files selected for processing (1)
.github/workflows/deploy-canary.yml
| VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }} | ||
| VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }} | ||
| VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }} |
4 participants
🔗 Linked issue
N/A
🧭 Context
Instead of using "branch tracking" on the canary Vercel env, this triggers a deploy from GitHub Actions on pushes to the
mainbranch in this repo. The branch tracking feature has limitations that this does not suffer from.📚 Description
Trigger a deploy to the "canary" env (main.npmx.dev) on pushes to the
mainbranch in this repo