WIP; do not merge - testing Vercel build triggers #39
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughTwo new GitHub Actions workflow files automate Vercel deployments. The preview workflow triggers on pull request events and deploys preview builds. The production workflow triggers on pushes to the main branch and deploys production builds. Both workflows use the Vercel CLI to build and deploy projects. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
Pre-merge checks✅ Passed checks (3 passed)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @.github/workflows/vercel-preview-deployment.yml:
- Around line 19-23: The workflow exposes VERCEL_TOKEN via CLI args; remove the
--token=... flags from the vercel commands (the lines invoking "vercel build"
and "vercel deploy" and "vercel pull") and instead inject the secret as an
environment variable by adding VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }} at the
job or step env level so the Vercel CLI reads it from the environment rather
than command-line arguments.
In @.github/workflows/vercel-production-deployment.yml:
- Around line 7-10: Add a concurrency section to the GitHub Actions workflow to
serialize production deployments: under the top-level trigger (after the
existing on: push: branches: - main), add a concurrency block with a descriptive
group name like "production-deploy" that includes the repository and github.ref
or github.ref_name to ensure only one deployment for main runs at a time, and
set cancel-in-progress: false so newer pushes wait and the latest commit is
deployed in order. Ensure the concurrency block is present at top-level of the
workflow YAML (same indentation as on: and jobs:) so it applies to the entire
workflow.
- Around line 20-24: Remove the --token CLI flags from the vercel commands and
instead export VERCEL_TOKEN as an environment variable for the steps;
specifically, update the steps that run "vercel pull --yes
--environment=production --token=${{ secrets.VERCEL_TOKEN }}", "vercel build
--prod --token=${{ secrets.VERCEL_TOKEN }}", and "vercel deploy --prebuilt
--prod --token=${{ secrets.VERCEL_TOKEN }} --yes" to drop the --token arguments
and add env: VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }} on the job/step that runs
these commands so the Vercel CLI reads the token from the environment rather
than exposing it in command-line logs.
🧹 Nitpick comments (5)
.github/workflows/vercel-preview-deployment.yml (3)
7-9: Add concurrency controls to prevent redundant deployments.Multiple commits to the same PR can trigger simultaneous preview deployments, wasting resources and potentially causing confusion. Add a concurrency group to auto-cancel previous runs.
🔎 Suggested addition after line 9
on: pull_request: types: [opened, synchronize, reopened] + +concurrency: + group: preview-${{ github.ref }} + cancel-in-progress: true
11-14: Add explicit permissions following least privilege.The workflow doesn't declare explicit permissions. GitHub Actions should follow the principle of least privilege.
🔎 Suggested addition after line 13
jobs: Deploy-Preview: runs-on: ubuntu-latest + permissions: + contents: read + pull-requests: writeNote:
pull-requests: writeis included if you want to add PR comments with deployment URLs later.
22-23: Consider capturing and sharing the preview deployment URL.The preview deployment URL could be captured and posted as a PR comment to improve developer experience. This helps reviewers quickly access the deployed preview.
🔎 Optional enhancement to capture and comment deployment URL
- name: Deploy preview - run: vercel deploy --prebuilt --yes + id: deploy + run: | + url=$(vercel deploy --prebuilt --yes) + echo "url=$url" >> $GITHUB_OUTPUT env: VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }} + - name: Comment PR + uses: actions/github-script@v7 + with: + script: | + github.rest.issues.createComment({ + issue_number: context.issue.number, + owner: context.repo.owner, + repo: context.repo.repo, + body: `🚀 Preview deployment ready: ${{ steps.deploy.outputs.url }}` + }).github/workflows/vercel-production-deployment.yml (2)
12-14: Add explicit permissions for production deployments.Following the principle of least privilege, declare only the permissions required for deployment.
🔎 Suggested addition after line 13
jobs: Deploy-Production: runs-on: ubuntu-latest + permissions: + contents: read
12-24: Consider adding production deployment safeguards.The workflow automatically deploys to production on every push to main without manual approval. Consider implementing additional safeguards:
- Use GitHub Environments with protection rules (required reviewers, wait timer)
- Add a manual approval step using
environment: production- Consider deploying only on tagged releases instead of direct pushes
🔎 Example: Adding environment protection
jobs: Deploy-Production: runs-on: ubuntu-latest + environment: + name: production + url: ${{ steps.deploy.outputs.url }} permissions: contents: readThen configure the
productionenvironment in your repository settings with required reviewers.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/vercel-preview-deployment.yml.github/workflows/vercel-production-deployment.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Deploy-Preview
🔇 Additional comments (1)
.github/workflows/vercel-preview-deployment.yml (1)
3-5: Environment variables are properly configured.The workflow correctly sets up Vercel organization and project IDs from repository secrets, which the Vercel CLI will automatically consume.
| on: | ||
| push: | ||
| branches: | ||
| - main |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Add concurrency controls for production deployments.
Without concurrency controls, rapid pushes to main could trigger multiple simultaneous production deployments. For production, it's critical to ensure only one deployment runs at a time and that the latest commit is deployed.
🔎 Recommended addition after line 10
on:
push:
branches:
- main
+
+concurrency:
+ group: production
+ cancel-in-progress: falseNote: Using cancel-in-progress: false ensures deployments complete in order rather than canceling in-progress ones.
📝 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: | |
| push: | |
| branches: | |
| - main | |
| on: | |
| push: | |
| branches: | |
| - main | |
| concurrency: | |
| group: production | |
| cancel-in-progress: false |
🤖 Prompt for AI Agents
In @.github/workflows/vercel-production-deployment.yml around lines 7 - 10, Add
a concurrency section to the GitHub Actions workflow to serialize production
deployments: under the top-level trigger (after the existing on: push: branches:
- main), add a concurrency block with a descriptive group name like
"production-deploy" that includes the repository and github.ref or
github.ref_name to ensure only one deployment for main runs at a time, and set
cancel-in-progress: false so newer pushes wait and the latest commit is deployed
in order. Ensure the concurrency block is present at top-level of the workflow
YAML (same indentation as on: and jobs:) so it applies to the entire workflow.
| run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }} | ||
| - name: Build | ||
| run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }} | ||
| - name: Deploy production | ||
| run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }} --yes |
There was a problem hiding this comment.
Token exposure risk in command-line arguments.
Passing VERCEL_TOKEN as a CLI argument can expose it in logs. Use environment variables instead, which Vercel CLI reads automatically.
🔎 Recommended fix to use environment variables for the token
- name: Pull Vercel env info
- run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
+ run: vercel pull --yes --environment=production
+ env:
+ VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
- name: Build
- run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
+ run: vercel build --prod
+ env:
+ VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
- name: Deploy production
- run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }} --yes
+ run: vercel deploy --prebuilt --prod --yes
+ env:
+ VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}📝 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.
| run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }} | |
| - name: Build | |
| run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }} | |
| - name: Deploy production | |
| run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }} --yes | |
| run: vercel pull --yes --environment=production | |
| env: | |
| VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }} | |
| - name: Build | |
| run: vercel build --prod | |
| env: | |
| VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }} | |
| - name: Deploy production | |
| run: vercel deploy --prebuilt --prod --yes | |
| env: | |
| VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }} |
🤖 Prompt for AI Agents
In @.github/workflows/vercel-production-deployment.yml around lines 20 - 24,
Remove the --token CLI flags from the vercel commands and instead export
VERCEL_TOKEN as an environment variable for the steps; specifically, update the
steps that run "vercel pull --yes --environment=production --token=${{
secrets.VERCEL_TOKEN }}", "vercel build --prod --token=${{ secrets.VERCEL_TOKEN
}}", and "vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}
--yes" to drop the --token arguments and add env: VERCEL_TOKEN: ${{
secrets.VERCEL_TOKEN }} on the job/step that runs these commands so the Vercel
CLI reads the token from the environment rather than exposing it in command-line
logs.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.