[Feature Request] Option to archive repository on destroy

[pmiles01]

[Feature Request] Provide 'Releases' data sourceHi there,

Given the example terraform

resource "github_repository" "new_repo" {

  name        = "new_repo"
  description = "My new repo"
  private     = true
  template {
    owner      = "joeblogs"
    repository = "my-template"
  }
}

You can terraform apply and it will create the repository as expected, and when you do a terraform destroy, it will delete the repository.

I'd like a new flag, something like 'archive_on_destroy' which would archive but preserve the repository on destroy.

So the new terraform could look like :

resource "github_repository" "new_repo" {

  archive_on_destroy = true
  name        = "new_repo"
  description = "My new repo"
  private     = true
  template {
    owner      = "joeblogs"
    repository = "my-template"
  }
}

[anGie44]

hi @pmiles01! I was looking into this more to see what's available in the current github API and it looks like on destroy, even if you had already updated the repo to set archived=true, the repo will not be preserved. would updating your config to set the archived param to true instead of callingdestroy work in your use case?

[pmiles01]

@anGie44 Thanks for looking at this request.

My particular use case is that I use Terraform to create a bunch of stuff, including git repositories, Google Cloud projects etc etc. The idea is that I use this Terraform every time our product team create a new product idea, and we need a space in which to work.

We use the destroy functionality of Terraform to mainly remove Google Cloud projects, service accounts etc, and ideally wanted to keep, but archive our Terraform created github repositories.

My work around at the moment is to use Terraform resource targeting to only destroy 'Google Cloud Project' related resources, and to specifically exclude my github module from the targeting. Personally I hate this approach, as it feels very wrong to use Terraform targeting.

Any thoughts or advice you have gratefully received.

[anGie44]

@pmiles01 i see, thanks for the context! hmm adding the alternative capability to the "destroy" functionality for this type of resource sounds plausible and I see where it would help in your case. let's see if there are additional side-effects to consider/feedback from the community about adding this feature :) @jcudit @patrickmarabeas @kpfleming

[pmiles01]

Once again, thanks for looking - excited to hear the wider communities thoughts ....

[jcudit]

@pmiles01 I am still trying to understand this project's position on adding value. For example, our underlying library presents the GitHub API to us with no added value and we layer on abstractions using the available primitives to add commonly used functionality.

I think its a useful feature but may only be applicable to users who share this preference. Embracing targetting or archiving and removing the repository from state are other solutions as well, but I am not sure how common these workflows are used. My vote goes to deferring the feature until it receives a few more 👍 s.

[patrickmarabeas]

I think this can be solved with Terraform modules - with the added benefit of being able to spin up an archived repository as well as all related infrastructure and resources:

Your module would implement a flag, with each resource using it within a count / for_each to determine if they should exist or not. In the case of the repository, it would use the flag to set its archived status. You would also want to include the prevent_destroy property in the lifecycle block to ensure the repository can't be deleted via Terraform.

The only "downside" is having an archive of old project configs marked as archived...

[anGie44]

@patrickmarabeas ah i hadn't considering using the lifecycle attribute! reading the docs it seems you may come across issues (https://www.terraform.io/docs/configuration/resources.html#prevent_destroy) but @pmiles01 would have to confirm. Alternatively, I believe you can use the state rm command before destroy. A bit more manual but you can update your repositories in question to archived=true, run the apply, then terraform state rm modules.your_module , for example, before running terraform destroy on your config. Additionally you'd have to remove the module/repositories resource blocks from the config to avoid re-creating (or already exists type errors from Github API) in future runs

[patrickmarabeas]

The lifecycle attribute won't do what he's hoping - it'll just error during plan/apply when you try to destroy the config. I only raise it as a fail safe to ensure repositories cannot be deleted.

[pmiles01]

@jcudit Hi Jeremy,
I hope you're well. Thanks for taking the time to consider my feature request. It looks like @anGie44 has kindly implemented it and its waiting for a review from you.

In these seriously unusual times, I appreciate that you are probably busy, but could you spare a moment to review and if possible merge @anGie44 changes.

Many thanks

[jcudit]

👋 I've got the review queued behind fixing tests over in https://github.com/terraform-providers/terraform-provider-github/issues/439. Once that is cleared and there is no additional friction after reviewing, this will likely ship with the next release.