Use cases for this action over official Vercel git integration?

[leerob]

Hello! I'd love to hear more about what this action aims to solve that the official Vercel git integration does not.

• What is missing from the official git integration?
• Why did you choose this over the default solution?
• What could we do better?

We'd had some confusion since this is not a official Vercel solution and I'd love to have some clarity. Thank you!

https://vercel.com/docs/git

[vadym-vorobel]

Hi @leerob! I just want to share my use case for this action with you.

We have our NodeJS application in a private GitHub repository. Also, it is using the NPM package with another private GitHub repository as a source.

To install this package I need an SSH key to be present in the SSH agent. Right now it's not possible with Vercel itself. See more in this issue - https://github.com/vercel/vercel/discussions/5274

So, we've decided to use GitHub Actions + this vercel-action to build the application correctly and publish it to Vercel.

I hope, it makes sense.

[leerob]

@vadym-vorobel thank you, that's very helpful 😄

[dszymczuk]

Hi @leerob
My case is to not deploy the application until the tests are passed. If tests pass, I can deploy the application.

[thedevdavid]

@leerob I second @dszymczuk

Also, if I only have 1 member on the Vercel team, none of the PR's made by my GH team members are deployed. I don't want to add my whole team just for the reason of deployment. We're a team of 4. That'd be $80 / month to let them deploy.

[euaaaio]

• Why did you choose this over the default solution?

Clarity and consistency. When everything related to CI is in one area, has its own structure and is managed by one technology. And not mashed into different interfaces that don't depend on you, work somehow differently, and can change to the worse at any moment.

[brandonarbini]

I'm using it to get around the monorepo limit that Vercel has. I have actions that run on changes to each deployable app in Github. Just like that...no more arbitrary limit. Thank you!

[leo]

@brandonarbini Thanks for sharing! Would you mind elaborating on which limit you mean exactly?

[dszymczuk]

@leo It means that if have monorepo (fe. 3 projects in one folder), you can't initialize 3 independent projects in each folder. You can initialize vercel project only on the root folder.
Check my issue: vercel/vercel#5294

[leo]

@dszymczuk That's an interesting issue – thanks for sharing it! But this issue right here is about why the GitHub Action would be used instead of our Git Integration, not about development.

Perhaps @brandonarbini is talking about how every Git repository on Vercel can only be connected to a fixed number of projects within a single Vercel Personal Account or Team?

[brandonarbini]

Yep, there are some limitations that I need to get around like the max of 3 projects for personal accounts and 10 for teams. I prefer to work in a monorepo for my personal projects and I have more than 3 there. Also, I just saw the "ignored build step" feature that wasn't there when I was getting things running initially. That will help a lot because I don't like building everything on every push. Ultimately, the limit of 3 on personal is limiting and upgrading to a team plan for $20/mo seems unnecessary since I only deploy changes to these projects very occasionally.

[leo]

I see. That makes a lot of sense, thank you! I'll bring this up to the team too.

[daiyi]

@leerob Hi there! My setup was too far off the platonic project shape and I was unable to get the build to work with the official git integration to work.

• lack of support for private submodules. The biggest blocker is that I could not find a nice way to get the official integration to authenticate with the dozens of private submodules in my project. I found this hack but I didn't like the complexity of adding a shell script. In GitHub Actions I was able to find a simple solution.
• I need to access the preview url for the build step of my project. I couldn't figure out how to do this in Vercel's native GitHub integration. I couldn't figure out how to do this with GitHub actions either, but I was able to find a workaround where I assign an alias based on the PR number after deploying.
• members of my GitHub org can transparently see and modify the build process without needing access to Vercel. I work on a project with rotating contractors coming and going frequently. It's a logistical pain to have to add and remove people to a vercel team who want to work on the build, and remove members in a timely manner as to not incur excessive costs. It's much simpler to move the build into GitHub Actions, and grant permissions one time through GitHub
• I didn't want deploys on every push/commit/branch, that's too much. I couldn't figure out how to turn that off in vercel, but I knew how to limit workflows to PRs only in GitHub Actions.

[barrymay]

@leerob Thanks for asking! After moving my project to a monorepo I needed to disable the git integration I was using for starters.

I second everything @daiyi mentioned, but I'll add a couple things:

• Similar to @daiyi I needed more flexibility with domain management. The domain manager in the vercel UI is acceptable (if I'm doing the git integration), but it's not sorted well which makes it clumsy, and I really want to organize and check that in somehow. I know Vercel has been trying to move to a no-config route for ease of use, but for advanced use-cases where automation is key, having good configured setups is really helpful. Since this is all done by Github Actions, and code-based, it's clear(er) to see what's going on

• For a monorepo, the latest yarn/npm workspace management support by Vercel is not quite there yet. I was trying upgrading to yarn berry workspaces (failed), then yarn 1 workspaces (worked but the vercel cached build was very slow), and then npm 7 workspaces (which works fine) after I fidgeted with the "Build & Development Settings" output folder. To get this kind of thing working in Vercel, I need more clear automation and this action definitely helps!

IMO, I think the Vercel CLI is still very helpful (for this kind of automation). I feel the Vercel "no-config" model works for base cases, but as projects need more features (or integrations with custom API cases), this can get tricky, and a good independent CI/CD deployment model (that can push to Vercel when required) is key.

To that end, IMO Vercel could better support advanced cases by allowing developers the flexibility to:

• Set their "Build & Development Settings" via repo config
• Allow deployments of pre-built next packages (for its advanced features, maybe Vercel could allow devs to have an output mode they could hook into when the code gets pushed across?)
• When a user is using the Vercel CI
  • Allow more control over when the git integration runs a build (it really doesn't have to be every build, it just eats unnecessary cycles)
  • Allow easy multi-cancellation of builds on the Vercel UI

[graup]

Hi @leerob and @leo

My use case is to deploy the production branch only when there's a tag in git.

[PaulRBerg]

Suggestion to move this to a GitHub discussion - but @amondnet must activate discussions in this repository first.

GitHub issues should be for specific bugs/ problems.