CLI deployment duplicated my project

Help
1

Hi all, not so much a question, but instead some concerning and unexpected behaviour when deploying via CLI…

I’ve got my own github org. which owns the repo associated with my vercel project. The project shows up in Vercel under the org as expected.

I’ve got no other repositories linked to my Vercel account, so when selecting a project, there are none under my name, but there is one under my organization name.

I created a token to start testing CLI deployments. When using a token scoped to my organization, I got an access denied error of sorts. So, I created a token scoped to my github username.

This token worked, however the deployment belonged to a new vercel project under my account that didn’t exist prior. It had none of the domains or environment variables that I’d configured. That is to say, it was effectively a new project.

2

Hi, @lauchlan105! Welcome to the Vercel Community :smile:

Thank you for taking the time to describe this! Let me try and help you out here.

From what I understand (please correct me if I’m wrong!), the unexpected behavior here is that using a personal token created a new project instead of updating the existing one under the organisation, right?

It sounds to me that this is likely because:

  1. The personal token doesn’t have access to the organisation’s projects.
  2. Vercel’s CLI, when unable to find a matching project under the authenticated scope (in this case, your personal account), might default to creating a new project.

To resolve this:

  1. Make sure you have the correct permissions in the Vercel organisation to deploy via CLI.
  2. Use a token that is correctly scoped to the organisation and has the necessary permissions.
  3. When running the deployment command, explicitly specify the project ID or name to ensure it’s deploying to the correct project.

Let us know if you have any more questions!

3

Hi Pawlean, thanks for the response.

I’ll give these a go and let you know how I go.
Cheers.

1 Like
4

Hi,

After mucking around with Github Actions for far too long I finally settled on a workflow that has worked for me.

The token issues were resolved when using a token with max permissions. I did not try to reproduce this using the org-scoped token, all I know is that the wider-scoped token is working. I don’t have any other projects so this is functionally no diferent. If I did have other projects this would not be a viable solution.

However now I’m facing different issues with URL aliasing/deployment naming/deployment promotions which I will create a new thread for if I can’t find any existing related topics.

If there’s a way to specify a local .env file to use when deploying, as opposed to passing --env for each variable you wish to include, I have opted to pull everything down from vercel, append the variables I want, build in the pipeline and deploy with a prebuilt dist.

vercel deploy --prebuilt --prod

However, despite having the --prod, it is not assigning my prod url alias, and I have to ‘promote’ my build. Secondly, the deployments are just called HEAD and I’m hoping there’s a way I can name the deployments.

5

Scratch that - it isn’t working

This has been an infuriating process. Most of it is unrelated to the task of “deploy from CI with a token”, but still very much to do with Vercel. After finnicking with this for two days, I have arrived at…

vercel deploy --prebuilt --prod --token=<full account access token>
vercel promote <deployment url> --token=<full account access token>

Why --prebuilt?

I want to include things like the commit hash and a version name of sorts, whether it be the branch or the release tag. I don’t want to have to specify --env for each variable I want to ship over to Vercel, plus I would like to be testing the build to be deployed. So I pull the desired variables from vercel, build, test and deploy.

Why vercel promote?

I’ll start with my UAT environment. Of all the other deployments I do for non-prod, only those issued from the main branch are visible from my nonprod domain. All other nonprod deployments are only visible from their vercel preview domains. This tells me the git ref influences the deployment environment, and the --prod flag only influences which environment variables are used.

Since I’m not deploying from a branch - but rather, a tag - this is the equivalent of a preview deployment with production environment variables.

But here’s the catch - the promotion fails due to permission issues, which takes us to…

Why use a token with full account access?

Previous attempts with the org-scoped token failed, and personal-scoped token was creating a new project. The full-account access token finally worked for pull environment variables, building and deploying (including deploying without a prebuilt).

Unfortunately, when I go to promote I receive…

Error: Deployment belongs to a different team

It seems Vercel is so tightly coupled to branch-based deployments that even your CLI tools can’t escape the side effects.

I feel defeated to find that the alternatives are either more expensive, or are bare-metal solutions. So by default I’ll reluctantly be sticking around with this. Please help.

1 Like
6

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