Send branch ref in Github deployment and deployment_status events

[jimCresswell]

Hi,

I'm building a fairly large project, currently hosted on Vercel. I want to trigger a suite of automated checks against PR preview deployments (and production deployments) triggered by pushes and PRs in Github.

I have that working, using the Vercel-Github integration, and Github workflows triggered on Github deployment_status events. However, within those events, both the ref and the sha field are set to the value of the SHA of the commit that triggered the build.

That means that within the Github workflow the context/env variable for the ref is undefined, e.g. GITHUB_REF="". That means the Github action actions/setup-node cannot be used with caching, see actions/cache#319 .

The lack of caching for Node dependencies significantly slows down Github CI/CD workflows triggered by Vercel deploys.

All of those deployments have an associated branch, either directly or as the head branch (feature branch) in the PR. Would it be possible to send that information in the ref field of the Github deployment and deployment_status events?

[danielgent]

This would make our DX so much better. For our CI/CD we need to set the current deploy URL as the Auth0 callback URL in an env var except on develop and main.

Doesn't currently look possible to do this

There are also other things like building Storybook on Vercel in the same repo. The Cypress CI/CD tests also fire for that as there's no way to differentiate in GitHub actions where the Vercel build has come from 🥲

[jimCresswell]

@danielgent depending on what your Storybook project in Vercel is called, you might be able to do something like

my_brilliant_job:
    # Only want to run on success, otherwise it might be "pending", or "failure".
    # Filter out non product deployments
    if: ${{ (github.event.deployment_status.state == 'success') &&  !contains(github.event.deployment_status.environment, 'storybook') }}
    steps:

[danielgent]

In github.event.deployment_status.environment I get Preview

I'm echoing this out now so when I do a prod release I will see what it shows. I'm guessing Production

I wasn't aware we could set up different environments in Vercel. I thought it was only Preview, Development and Production (and development is only for running locally in dev mode)

[jimCresswell]

I would have expected something like Preview - <name of your Vercel project> but maybe we have different set ups

[rkreicbergs-sorsera]

Is there any update on this from Vercel side? Are we missing something? This seems like an obvious thing to do - if a commit on a specific branch trigger deployment, then Vercel should provide the same info back on deployment_status event. Is there a way to detect the branch from the event?

Our problem. We use stage and production environments, each with a fixed domain. We don't have an issue for production environment, but we keep struggling with properly setting up a stage environment. For the app itself, we use NEXT_PUBLIC_VERCEL_GIT_COMMIT_REF to recognize both stage and production environments. But we cannot figure out how to properly run E2E tests for Stage. We can detect production environment using github.event.deployment_status.environment and for feature branches we use *.vercel.app URLs, but we cannot figure out how to propely run our Staging E2E tests with the proper custom domain we have assigned to it.

[jimCresswell]

@rkreicbergs-sorsera you can dump out the entire GitHub event metadata with a re-usable workflow like

# .github/workflows/reusable/dump_event.yml
on:
  workflow_call:

jobs:
  run:
    name: dump GitHub event
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo GITHUB_ACTION: $GITHUB_ACTION
          echo GITHUB_WORKFLOW: $GITHUB_WORKFLOW
          echo GITHUB_EVENT_NAME: $GITHUB_EVENT_NAME
          echo GITHUB_EVENT_PATH: $GITHUB_EVENT_PATH
          cat $GITHUB_EVENT_PATH

and then use it like

name: Deployment Status Actions

on: deployment_status

jobs:
  dump_github_event:
    uses: ./.github/workflows/reusable/dump_event.yml

that should show you all the data you have to play with. You can also write a custom JavaScript action to determine the branch a commit came from by comparing the commit to the HEAD of each branch, odds are only one branch has the commit you care about as its HEAD.

[rkreicbergs-sorsera]

@jimCresswell Thanks for the very useful answer, will definitely use cat $GITHUB_EVENT_PATH in the future for debugging GitHub actions.

That said, this seemingly confirmed that Vercel does not send anything that specifies which branch the deploy is for.

I guess we could compare the commit with HEAD of main branch - as we delete feature branches after merging and we can distinguish production branch with the info from Vercel bot. Seems hack-ish... but if it works, might just as well do it :D

Still, it would make sense if Vercel bot would just add the branch info to the event :)

[jimCresswell]

I do agree, it would be very helpful if Vercel added the branch info to deployment related events

[omxela]

I've been trying to use GHA on: deployment_status to unpause CI tasks upon completion of Vercel preview deployments. The goal is to run cypress test against Vercel's significantly quicker builds than in bulky CIs. It doesn't work.

It looks like Vercel is targeting the HEAD commits of the branches instead of the branches themselves. So the GITHUB_REF (filled in by Github instead of being returned by Vercel, see https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#deployment_status ) of an event is always empty.

This also breaks Branch protection rules / Require deployments to succeed before merging.

[giovai]

Are there any plans to introduce the source branch in the event sent to Github?

[esbanarango]

Facing a major blocker because of this 🙏

[giovai]

I ended up using a git command to get all branches that contain the commit, since in my case it's a merge commit that will only be available on the specific branch:

     - name: Get Deployment Source Branch Name
       id: git-branch
       run: |
          git branch -a --contains ${{ github.event.deployment.ref }}
          source_branches="$(git branch -a --contains ${{ github.event.deployment.ref }})"
          result=$(echo "$source_branches" | tail -n1 | sed 's/^[ \t]*//') 
          echo "Remote source of deployment: ${result}"
          echo "Local git ref of deployment: ${result#remotes/origin/*}"
          echo "SOURCE_REF=${result#remotes/origin/*}" >> "$GITHUB_OUTPUT"
     - name: Checkout 🛎
       if: steps.git-branch.outputs.SOURCE_REF  == 'build'```

[bartvdbraak]

Thanks for this suggestion!

I needed to add git fetch --all at the beginning of this to work:

     - name: Get Deployment Source Branch Name
       id: git-branch
       run: |
          git fetch --all
          git branch -a --contains ${{ github.event.deployment.ref }}
          source_branches="$(git branch -a --contains ${{ github.event.deployment.ref }})"
          result=$(echo "$source_branches" | tail -n1 | sed 's/^[ \t]*//') 
          echo "Remote source of deployment: ${result}"
          echo "Local git ref of deployment: ${result#remotes/origin/*}"
          echo "SOURCE_REF=${result#remotes/origin/*}" >> "$GITHUB_OUTPUT"

[stephenhmarsh]

+1 for this. We want run our Playwright e2e tests against our Vercel deploys but this is very wasteful because there's no way to cache the npm ci step when the job is triggered from deployment_status event, without the branch ref apparently. This means about 1 solid minute of computation and heavy network usage, for no reason, every run. (Plus, like, making the whole process about 90+ seconds slower), and all of this eats into our GitHub actions quotas.

[amerfarooq]

Hoping something like this get implemented soon!

[ch4r-ch4r]

+1

[ksandrsis]

+1

[jimCresswell]

I feel weird +1ing my own issue, but this is still important

[giovai]

This is available at request on Enterprise accounts, per Github organisation. Upon request, Vercel sends the branch ref instead of SHA.

[jimCresswell]

That's good to know, but I feel that for events associated with a pull request, the correct value for the ref is the source branch ref, especially as the SHA is already available in another field.

[MinyoungRsup2]

Was this process easy? Running into the same problem and deciding to send a support ticket...

[giovai]

@MinyoungRsup2 yes, I simply asked the same question raised in this issue and included the link to it for clarity. In response, Vercel enabled the source branch ref straight away.

[joaovinicius]

+1

[3runo]

+1

[jhopley-stadion]

+1

[ucheol2]

+1