CLI doesn't send gitSource during deployment. The Git branch URL is not generated

Hello everyone,

I’m using GitHub with Vercel and would like to deploy my project using a combination of GitHub Actions and the Vercel CLI.

However, I’ve noticed that when deploying via the Vercel CLI, the Git branch URL is not generated.
Upon investigation, it seems this issue is due to the CLI not sending the gitSource.

Question:

Why doesn’t the CLI send the gitSource?
If there isn’t a specific reason for this, I would like to propose a fix that enables the CLI to send the gitSource and submit a PR.

CLI Version:

$ verce--version
Vercel CLI 37.2.1
37.2.1

Note:

There seems to have been a similar discussion in the past, but it appears that it was not addressed.

Hi, @yuta0428!

Thank you for your patience. :smile:

I checked with the team and found that the gitSource doesn’t make sense for CLI deployments because the deploy was not initiated from a git provider. The CLI simply deploys local files which may have changes that aren’t reflected in the git provider repo.

Hi @pawlean !
Thanks so much for taking a look at this.

I wanted to share a few thoughts in response to your points.

The CLI simply deploys local files which may have changes that aren’t reflected in the git provider repo.

I totally understand your point. Since the current implementation relies on the file parameter, there’s a possibility that using gitSource could result in deploying files that differ from the contents of the git repository.
That said, the CLI is really just making API calls under the hood, so I don’t see that as a reason why the CLI wouldn’t be a good fit here.

In fact, when using GitHub Integration or Vercel Deploy Hooks, git clone is executed on the Vercel side during deployment. I think it would be great if the CLI could replicate this behavior. This would help avoid obstacles when transitioning to the CLI while building custom deployment environments.

From a functional perspective, I don’t see any issues with implementing gitSource as an option. What do you think?

For example, something like this could work:

vercel deploy --gitsource=github --token=xxx

This could help avoid mixed-up deployments and offer more flexibility in the deployment process. I’d love to hear your feedback on this!

1 Like

Thanks for the thoughtful response, @yuta0428! I’ve shared this with the team that look at the Vercel CLI and will get back to you on any feedback. :smile:

Hello @yuta0428!

Thanks for describing your thoughts in detail. We agree that we’d like Vercel CLI deployments to act more like git provider integration deployments. This is something that we’re addressing over time.

For the git branch specifically, we’d have to use Vercel CLI to trigger the deployment such that the git provider integration is used to clone the repository. This is a different kind of deployment than Vercel CLI’s typical scenarios. We’d have to make the usage and output clear about what’s happening.

I think this would be neat, but not sure how much usage it would get. We’ll keep track of the feature request and see if it becomes more useful and/or requested over time.

Clarification: The git metadata (most notably local branch) is passed along for Vercel CLI deployments for display in the dashboard. It’s just not otherwise treated as a git provider deployment.

Note that you can do this kind of thing through the UI: Deploying Git Repositories with Vercel

2 Likes

Hello @seanmassa-vercelcom !

I’m glad to hear that you share the same thoughts. I also understand that the feature will be addressed if there’s enough demand for it.

Thank you for the clarification as well. You’re referring to git metadata, right? Yes, I’ve already gone through the code and debugged it, so I’m aware of that.

That said, would it be alright if I proceed with creating a PR for this feature?
I’m not particularly strong in TypeScript, so it may take some time, but I’d love to contribute toward making this a reality.

Hello, chiming in here. @rlesser and I have also been discussing this in another thread. We’re of the same mind as @yuta0428 that we’d like our github actions to mirror as much of the git integration functionality as possible. So hopefully this shows that there’s more support/desire for this change.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.

I’m going to turn this into a Feedback topic so it can be used to collect more input about this idea

3 Likes