Deployment made from github action does not have branch

[rlesser]

I am in the process of migrating from the vercel github integration to the vercel CLI + github actions for build and deployment of preview branches.

I am running into an issue where the CI-created deployments do not get the right branch or commit name, and therefore to not get a branch-specific URL.

Here’s what my deployments look like with the integration:

And here’s what they look like with the ci-based deployment:

I read through this thread about a similar migration, but could not find any solution: Switching from github integration to manual CI/CD through github actions

I tried adding --git-branch=${{ github.head_ref }} to my vercel pull command, but that didn’t help either. It feels like there’s some env variable or argument that the vercel github integration is using that I’m missing.

Would appreciate any help or advice on this! Let me know if more context is needed.

[omn1coreprocessing-g (0mn1core)]

Hey! Glad that thread was at least adjacent to things other people want to do!

Looking at my deploys from my github workflows, I do seem to have the branch correctly attached to the deployment:

Though looking through my workflow, I’m not quite sure how Vercel is getting that information. Maybe it grabs it from the git environment somehow during vercel build or vercel publish? How does your workflow check-out the code? I’m using the latest version of actions/checkout to do it. Possibly if you’re manually running git checkout commands, it thinks you’re on a specific commit rather than a whole branch?

[rlesser]

Hey - thanks for that thread, it was really helpful!

I believe I’m using a very similar job to yours, at least the one from your sample repo:

deploy_preview:
    name: Build and Deploy Preview to Vercel
    runs-on: ubuntu-latest
    needs: optimize_ci
    if: needs.optimize_ci.outputs.skip == 'false'
    outputs:
      preview_url: ${{ steps.preview-deployment.outputs.preview_url }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v4.1.7
      - name: Install Vercel CLI
        run: npm install --global vercel@latest
      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=preview --git-branch=${{ github.head_ref }} --token=${{ secrets.VERCEL_ACCESS_TOKEN }}
      - name: Build Project Artifacts
        run: vercel build --token=${{ secrets.VERCEL_ACCESS_TOKEN }}
      - name: Deploy Project Artifacts to Vercel
        id: preview-deployment
        run: |
          preview_url=$(vercel deploy --prebuilt --token=${{ secrets.VERCEL_ACCESS_TOKEN }})
          echo "preview_url=$preview_url" >> $GITHUB_OUTPUT

Its worth noting that I use Graphite, so most of the updates to my PRs are coming as rebases. I don’t see why that would pose a problem as its all still within the same branch…

[omn1coreprocessing-g (0mn1core)]

What’s the top level on directive look like? If it’s set up to run on individual commits rather than on pushes to branches, I’m wondering if github actions populates the environment differently.

[rlesser]

Pretty basic setup:

name: Preview CI/CD
on: pull_request
permissions: write-all

env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

[omn1coreprocessing-g (0mn1core)]

Ah so it’s a pull request, I have the workflow for it but haven’t tested it out. In bitbucket/gitlab I think that the ref gets set to the PR number, assumed it was the same for github but guess it’s just the commit tag unfortunately. I’m not seeing any options in the deploy command documentation for manually setting the branch name. If someone more familiar with vercel command line can chime in and mention what deploy uses to get the source data, could try mocking that to return github.head_ref possibly?

[rlesser]

Hm, I didn’t even realize there was a difference in trigger conditions in your example. That seems to be the reason. If there’s not an easy fix (but I hope there is!) I probably can switch my trigger from pull-request to push in order to fix this.

[rlesser]

I switched the triggering action from pull_request to push and got a surprising and disappointing result:

Somehow vercel correctly learned that there was a branch attached to this deployment, but it did not create the branch-specific URL, which is what my goal is. @omn1coreprocessing-g - does your version of this create the branch-specific URL?

Still something missing here about how Vercel does this. Would love to here from them on the right way to accomplish this and get the same behavior as the integration.

[omn1coreprocessing-g (0mn1core)]

Hey, sorry for late response. Just made a branch on my template project and am also seeing the same thing. Looking back at my old integration deployments, they had the “branch” icon for the top domain (express-typescript-vercel-template-git-main-0mn1cores-projects.vercel.app) and the “single node” icon for the second domain (the one that puts the deploy name in the link), whereas the deployments from the git icons have the “globe grid” for the top domain ( express-typescript-vercel-template-0mn1core-0mn1cores-projects.vercel.app, looks like it’s using either my git or vercel username possibly?) as well as the “single node” icon domain, same as the integration behavior.

Would definitely like to know how to get the behavior squared away to be as similar to the integration as possible. Want the resultant deployment output to be as identical as possible while still allowing me control over the builds (which I need anyways since typescript and it needs to be built, which you can’t do correctly with the integration). If anyone more familiar with Vercel CLI or the git integration can comment where I’m not sufficient with my workflow, would greatly appreciate it.

[rlesser]

I’ve had the exact same experience @omn1coreprocessing-g. Additionally I’ve tried the following tests:

• setting --build-env flags for the VERCEL_GIT_[…] variables to communicate repo/PR information in my vercel deploy --prebuilt call
• doing the same but with --env flags
• doing the same but letting vercel handle the build and deploy steps (i.e. vercel deploy w/o --prebuilt).

None of these have worked. I still just get HEAD as the branch, a git username in the globe URL, and a random merge commit as the commit.

This is very frustrating, and it feels like Vercel doesn’t want to allow the same functionality if you don’t use the integration. Would love to hear from someone at Vercel if there’s any possible solution here for my team.

[omn1coreprocessing-g (0mn1core)]

Yeah, it’s confusing trying to pin down what triggers this behavior. I don’t think it’s really Vercel not wanting to allow the same functionality for CLI or CI/CD builds, as there’s really no vested interest in them doing that; the github integration is great for getting people up and running and into the ecosystem, but there’s really no reason to keep functionality only relegated to the integration, especially since it can’t even work with Github Enterprise Server or people might have use cases like mine that prevent it. I think it’s just a case of poor documentation.

I’ve tried looking at the source code for the CLI in the repo. I found a create-git-meta function for adding metadata to a deployment, but nothing seems to be related to any branch data. I guess it’s possible the git integration doesn’t make use of the Vercel CLI, but that would seem weird. Is there any way to look at the source code for the Git Integration itself? Couldn’t find it in that repo or anything similar in any of their other repos.

[omn1coreprocessing-g (0mn1core)]

@rlesser not sure if you saw it, but I tagged you and referenced this thread in another thread discussing this. Apparently it’s currently not a capability of the CLI, and they say they’re keeping track of the feature request to see if it’s useful/requested.

[rlesser]

Thanks for flagging that @omn1coreprocessing-g - was disappointing to see that it is just fully unsupported. This is pretty limiting to our ability to scale our dev work with Vercel.

Would love to advocate for the use of that somewhere, especially since a single new arg to the CLI (or even just the CLI looking at the git environment itself) would solve the problem.

Would be great to hear from someone at vercel (i think I saw @pawlean earlier in the thread) about whether this can happen in the near-term, or where I can post this kind of request to see what the demand is.

[amyegan]

Thank you @omn1coreprocessing-g for linking this conversation in the other thread!

I’ll do my best to link related conversations there as I see them. If either of you see similar posts, please add the links there or tag me so I can do it. If we can build a list showing how many people are interested in the feature, that will help the engineering team as they determine priorities and plan future work.