terraform-provider-github resource/github_repository: Renaming forces new resource

Terraform Version

v0.10.2

Affected Resource(s)

github_repository

Terraform Configuration Files

resource "github_repository" "example" {
  name = "example-rename" # Change this
}

Expected Behavior

The repository should have been renamed without triggering the "forces new resource" behavior.

Actual Behavior

The plan shows the repository as requiring recreation.

Output

-/+ github_repository.example (new resource required)
      full_name:          "Example/example-rename" => "<computed>"
      git_clone_url:      "git://github.com/Example/example-rename.git" => "<computed>"
      http_clone_url:     "https://github.com/Example/example-rename.git" => "<computed>"
      name:               "example-rename" => "example" (forces new resource)

Oct 20 '17 17:10 taiidani

could anyone please review the linked PR? Thanks

Feb 13 '18 23:02 eugenetaranov

This would definitely be preferable to having to remove the state, rename the repo in GH, and then re-import the state, which is what we're doing now.

Jul 03 '18 14:07 mplanchard

https://github.com/terraform-providers/terraform-provider-github/issues/17#issuecomment-310893940

@radeksimko I saw you closed some of the other versions of this, we probably should leave at least one of them open as people keep creating new issues and we might as well keep one open with the context.

Nov 16 '18 23:11 majormoses

This is the current workaround https://gist.github.com/macropin/49f8a3c72afc157fa0d81688d26af677

Feb 28 '19 03:02 macropin

This is the current workaround https://gist.github.com/macropin/49f8a3c72afc157fa0d81688d26af677

I do something similar but with a terraform state mv [old] [new] instead of a remove and import. See the docs for full usage. I do a remove from state is when deleting repos (as we dont give our bots the ability to delete) or when I need to switch the provider associated with it (less common with github than say aws), Keep in mind that it won't move child objects which I think is probably true in the case of sub objects (such as permissions, branch protections, etc) as well with an import.

Feb 28 '19 04:02 majormoses

@radeksimko I believe Github's API provides renaming support https://developer.github.com/v3/repos/#edit. I haven't verified it myself yet, but there are multiple stackoverflow answers confirming this behavior https://stackoverflow.com/questions/4777535/how-do-i-rename-a-github-repository-via-their-api.

Do you accept PRs supporting renaming?

Jan 10 '20 14:01 grobie

there is relevant discussion on #65 that would be useful to anyone looking to submit a PR it requires a bit of refactor to leverage the repository id (not documented) internally with terraform so it can know the difference between a rename and a delete and create.

Jan 11 '20 06:01 majormoses

Indeed, any resource which can be renamed should be identified by its permanent identifier inside Terraform (and in the Terraform configuration); I've done a bunch of work in that area for identifying users already, but it could be done for repositories as well.

Jan 11 '20 12:01 kpfleming

Is the idea to pass around the repository id and look up what name the id is associated with (give all APIs are org/name based), while using the id in place of the repository name? Are calls cached by default? Happy to kick off this refactor if this is the way to go.

Mar 10 '20 00:03 patrickmarabeas

(id being node_id from which we derive the id from)

Mar 11 '20 01:03 patrickmarabeas

Is this still an issue? Doesn't seem so as the nameattribute doesn't have ForceNew: true anymore and with the latest version 4.29.0 it seem to work out of the box. Can somebody confirm that this is intentionally working?