I think we should probably validate that one of files or git_source is present.

on it

this has been done in https://github.com/vercel/terraform-provider-vercel/pull/21/files#diff-03202b30898c33935f6776c185f1dd43d67d1d5c6e81fd443eb3a88bb45f4154R212-R220

How are these all optional? Aren't they required if specifying a git_source?

I set them as required, let me check why they appear as optional in the docs

I was investigating a bit and could not find why this happens. tfplugindocs just renders them as optional even when they are set as required. if happens the same here

Ahh interesting. I guess it's because the parent property is optional then.

Why not:

return client.GitSource{
   Ref: g.Ref.Value,
   RepoId: g.RepoId.Value, 
   Type: g.Type.Value,
}

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 :)

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 suspect the snake case here isn't correct.

mmm, as per their recommendations it looks fine:

Attribute names within Terraform configuration blocks are conventionally named as all-lowercase with underscores separating words, as shown above.

feel free to change it if you think it is more consistent

This is the json response from the Vercel API, so not to do with the terraform configuration :)

you're right, I just tested it

    },
    "gitSource": {
        "repoId": 449314886,
        "ref": "dario-terraform-deployment-test",
        "type": "github",
        "sha": "f4f09e995618dea3cd77e39a2cb710628ae03228"

changed

Hooray. We should probably set this back onto the terraform state, rather than using the value from plan in that case (so it's readable). However... I think we probably need to fix the repoId issue with different git providers first.