Digging into this, where does the repoId come from?
I can see in the example that you have it as a number. 🤔. I wonder if we need some data source to expose this so it's more usable?

Okay, so repoId looks like it is exposed through a project. I think it could be exposed from both the vercel_project resource and the vercel_project data source.
This would mean you can use it like:

data "vercel_project" "my_project" {
   name = "my-project"
}

resource "vercel_deployment" "example" {
  team_id    = var.vercel_team_id
  project_id = data.vercel_project.my_project.id
  git_source = {
    ref = "main" // or any other branch you fancy. 
    repo_id = data.vercel_project.my_project.git_repository.repo_id
    type = data.vercel_project.my_project.git_repository.type
  }
}

I think this would be more preferable than having to dig out a repoId. What do you think @WCMinor?

Another issue I can see here is that Terraform would not know when the vercel_deployment resource needs re-creating. Short of having something like the ref set to a specific commit ID. So this would only act as a one-off deployment.

https://stackoverflow.com/questions/13902593/how-does-one-find-out-ones-own-repo-id
The number provided in the test is your repo btw

That's true that you can find it out that way, but I think it's somewhat surprising to see (and results in a magic number). I think if we had the data source, or exposed it via a project it would be more intuitive on how to use the two together to trigger a deployment.

Out of curiosity have you considered putting them in a single repository, behind something like https://turborepo.org/ ?

we're actually moving on from a monorepo to a distributed system to allow each team to manage their own code as the teams get bigger

Makes sense! As an update on this issue - I've been having a play around, and I'm coming to the belief that the only thing needed is a ref field on the vercel_deployment resource.

For example

resource "vercel_project" "example" {
   name = "my-test-project" 
   git_repository = {
       type = "github" 
       repo = "acme/example"
   }
}

# Deploy the main branch of acme/example. 
resource "vercel_deployment" "example" {
    project_id = vercel_project.example.id
    ref        = "main" # or a commit ID. 
}

The deployment resource can, itself, look up the relevant repoId / equivalent bitbucket/gitlab parameters, and pass these onto the deployment creation.

You could even use it with a data-source to pull a project by a name:

data "vercel_project" "example" {
    name = "my-test-project" 
}

resource "vercel_deployment" "example" {
    project_id = data.vercel_project.example.id
    ref        = "main" 
}

We already have a hard requirement that for a deployment to be created, a project must already exist. I think using the git-connection this way would work nicely, and also prevents any confusing fields being presented back out of the provider (like repoId or projectUuid or workspaceUuid). What do you think @WCMinor? Would this work for your use-case?

With my playing around I think i'm fairly close to a working version, so if this works for you, I should be able to have a PR up soonish.

This looks great yeah, much easier to understand and to configure.

Funny enough, if you pass a public github repo (not configured in your project) to the deploy API , it works, it deploys a project based on such public repo. That is the only case in which it would make sense to use a standalone git_source parameter. Honestly, I think that functionality is kinda out of the scope of this provider as it is not really documented by Vercel.

Yeah. It's probably more a result of accidental API design than anything else 😓

I think we'd also want to add acceptance tests specifically around creating a resource_deployment with git_source set.

working on these

done

I think we can do this as a validation instead, but I'll merge the changes and fix this up retrospectively.

that makes sense

just to clarify, are you merging this or you require more changes?

Sorry, i wasn't very clear. I meant i'd take a look at fixing that (either post merge, or by checking out your branch). I've only had a surface level skim so far :)