Questions about an upgrade of Github provider from v2.8.0 to v4.17.0

Terraform Providers
1

I’m stepping through an update from Terraform 0.12 to 0.13 (and then onwards) on some infrastructure that uses the Github provider to manage many Github repositories, teams etc.

This infrastructure is currently using an apparently-very-old copy of the Github provider, v2.8.0 - you can’t even find docs for it anymore without digging into the repo, and so I’m also updating it to use the latest v4.17.0.

The newer version of the provider is quite different from the old. Repositories used to have a ‘default_branch’ attribute but that is now deprecated, and there is a new resource ‘github_branch_default’.

I have gone and made github_branch_default resources for all of my repositories that had the default branch set.

My question is, in a plan, this obviously shows the new resource is going to be added.

  + resource "github_branch_default" "default_branch" {
      + branch     = "main"
      + id         = (known after apply)
      + repository = "my-repository"
    }

If I apply this, is anything strange going to happen if this repository already has this branch set as the default? Like, it won’t try and create the branch, right? And if it’s already the default, is it likely to throw an error?

My other question relates to the new ‘visibility’ attribute of the github_repository resource. Previously (on the older module) I was using private= true|false which is also deprecated. Now when I add the visibility attribute, I can see it will be added - no problem - but what is strange is that another engineer in my team is running terraform plan and seeing that the visibility attribute is already there.

We are both using the same provider version and same Terraform 0.13.7, with a shared remote state (S3 bucket), and nothing has been applied yet using the newer versions… can anyone explain why this might be the case?

I have hundreds of repositories, so you can understand I’m hesitant to apply without knowing exactly what’s going to happen :slight_smile:

Thanks for any assistance!

2

I’m going through something similar, although it’s a little bit of work, I actually did it as an import rather than a plan/apply.

Create the empty resource, then import the resource, read the state and add in the attributes to the original resource, then run a plan to make sure nothing is being done to the object. If there are a lot of repeats you can figure out the pattern pretty quick. It seems safer than running an apply in an environment that can’t be easily replicated for testing nor can it be backed up in case of disaster.

3

Thanks for this! I agree, it’s starting to look like import is the safest option for sure.

For the default branch resource, how are you finding the ‘real’ resource ID in order to do the import to map it to the resource name in Terraform?

EDIT Ahh, I see in the docs, that the resource address/ID can just be the repo name itself!

terraform import github_branch_default.branch_default my-repo

4

Still want to know the same thing how to get that ID to import existing default branch =D