Hi Jonghun!

Great question. You've touched on some important aspects of Vercel's environment handling. Let me clarify a few points and suggest a workable solution:

1. The Pro plan limitation you mentioned applies to custom environment variables, not system ones like original_environment and environment. These system variables are internal to Vercel and can't be directly overridden, regardless of the plan.
2. You're correct that the API modifies original_environment and environment. This is by design and part of Vercel's deployment process.
3. Instead of trying to override these system values, you should: a) Use Vercel's built-in environment detection b) Structure your application to handle environment-specific logic based on other available environment variables

Here's an example of how you can achieve this in your GitHub Actions workflow:

1
name: Deploy to Vercel
2
on:
3
  push:
4
    branches: [main, staging]
5
jobs:
6
  deploy:
7
    runs-on: ubuntu-latest
8
    steps:
9
      - uses: actions/checkout@v2
10
      - name: Deploy to Vercel
11
        env:
12
          VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
13
        run: |
14
          npx vercel --token ${VERCEL_TOKEN} \
15
                     --env APP_ENV=${GITHUB_REF##*/} \
16
                     --prod

This approach:

1. Uses the GitHub ref to set a custom APP_ENV variable
2. Deploys to Vercel using their CLI, which respects the automatic branch detection
3. Allows you to use APP_ENV in your application to determine the environment, rather than relying on Vercel's system variables

In your application code, you can then use APP_ENV (or VERCEL_ENV if you prefer Vercel's built-in variable) to handle environment-specific logic.

Let us know how you get on!

Thank you for your response! However, it was slightly off-topic.

Here’s the exact issue I want to solve: I've developed a GitHub Action that triggers when a deployment to dev or another feat branch is successfully completed.

However, due to Vercel's nature, when merging feat -> dev and the deployment completes, two Preview deployments are created. As a result, a single commit triggers two deployment notifications.

To address this, I considered using commit ref or SHA to determine a unique value, but I couldn't find a way to make it work (or maybe I'm missing something).

Additionally, this GitHub Action is not limited to Vercel notifications but is meant for general deployment notifications.

For reference, I am not considering using the Vercel CLI.

P.S. I have confirmed that custom env works correctly and have tested it successfully. However, even with the PRO plan, only one custom env can be used, which significantly limits its usefulness. The difference in capacity between the PRO and Enterprise plans is too large.