[Vercel] Control permissions using GitHub Actions.

The server was running on Vercel and the source code on Next.js.

During operation, the Vercel administrator and the source code administrator were separated, and it became necessary to separate the permissions that each could access.

Now, the repository was accessible from Vercel’s GitHub Connection, so as long as they could log in to Vercel, they could access GitHub.

In order to divide this into different permissions, we decided to separate the access permissions by deploying to Vercel from GitHub Actions.

Set up GitHub Actions for Vercel.

Create a file to do GitHub Actions for Vercel. In this case, we will create two types of files: preview and production.

.github/workflows/preview.yaml

.github/workflows/production.yaml

preview.yaml

This action is executed when code is pushed to a GitHub branch.

name: Vercel Preview Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    branches-ignore:
      - main
jobs:
  Deploy-Preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install Vercel CLI
        run: npm install --global vercel@latest
      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}
      - name: Build Project Artifacts
        run: vercel build --token=${{ secrets.VERCEL_TOKEN }}
      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }}

production.yaml

name: Vercel Production Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    branches:
      - main
jobs:
  Deploy-Production:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install Vercel CLI
        run: npm install --global vercel@latest
      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

Creation of access tokens.

Accessed at https://vercel.com/account/tokens.

Create Token on the Account Settings page.
Give it an easy-to-understand TOKEN NAME, select your project for SCOPE and any value for EXPIRATION and click Create.

Creation completed. Be sure to copy and note the Token value shown.

Vercel Login authentication via CLI

Install and run the Vercel CLI.

Generate project.json for Vercel.

Create a new Vercel project.

$ vercel link

When you run it, you will be asked if this project path is OK, enter Y.

Select the relevant Vercel project.

Check the project and press Y.

If this is the case, OK.

A .vercel folder is generated and the projectId and orgId are stored in project.json.

Setting up a Secret on GitHub

Navigate to the target GitHub repository for which you want to do GitHub Actions to Vercel.

Go to Settings and click on Secrets and variables under Security.

Here, three secrets are set: VERCEL_TOKEN VERCEL_ORG_ID VERCEL_PROJECT_ID.

The VERCEL_TOKEN is created at https://vercel.com/account/tokens.
VERCEL_ORG_IDVERCEL_PROJECT_ID is set as defined in .vercel/project.json.

Select ‘New repository secret’, enter it and then Add secret and you’re good to go.

Deploying to Vercel using GitHub Actions.

Now that the configuration is complete, you can try out the workflow.

Create a PR on GitHub.

It will then automatically recognise the PR and create a Preview Deployment using the Vercel CLI.

This will happen when completed.

Click View deployment to see a preview environment.

Once the pull requests have been merged, a production build is created and deployed.

Summary

The fact that the preview environment is automatically created just by creating a PR is going to be useful for review checks.

This time, I changed it with the intention of separating the permissions of those who access the Vercel server and those who access the source code, but CI/CD never makes me unhappy when I build it, so this configuration seems to be good from the start.