Add ignoring feature for archived repositories

[lens0021]

This is a feature request.

Recently, I have archived a repository that has issue labels are managed by Terraform. When I try to delete the declarations of labels in my tf file, Terraform fails to delete the labels. I do not want to delete the issue labels, they are in a repository already achieved and I don't want to touch them.

Terraform Version

• Terraform v0.14.8
• provider registry.terraform.io/integrations/github v4.6.0

Affected Resource

• github_issue_label

Debug Output

Error: DELETE https://api.github.com/repos/femiwiki/kubernetes/labels/REL1_35: 403 Repository was archived so is read-only. []

Expected Behavior

delete_on_destroy argument or something similar to the lifecycle Meta-Argument to avoid situations like above is provided

Actual Behavior

I have to remove the state manually, probably.

Steps to Reproduce

1. Create a resource or import the state related to a repository.
2. Archive the repository.
3. Try to modify or delete the resource.

[github-actions[bot]]

👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!

[kfcampbell]

I think this issue is still valid so I've removed the stale tag for now. PRs are appreciated!

[owlot]

We have the same type of issue with handling repository file with Terraform and archiving a repository. Terraform will still try to apply changes to the files, and we have no way to prevent it other than manually removing all the Terraform managed files from the state when archiving.

[github-actions[bot]]

👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!

[SebasAnasco1517]

Is this somehow took into account in a new version?

[jmalloc]

Such a feature would be fantastic for github_repository_file. In my case it's that I don't want to update the file content for archived repos, which fails with the same 403 Repository was archived so is read-only. error.

[EraYaN]

This would solve a bunch of problems because the repo itself is often first in the apply tree because all the other things like branch protection stuff and labels depend on it. So archiving via Terraform just breaks everything. Not sure what the correct solution is though, maybe ignore all changes when it depends on an archived repo and reapply all those pending problems when the repo is unarchived?

[gallowaystorm]

Following up on this to see if there is progress? This would give us the ability to keep the repos in state (if we ever need to unarchive them) and keep clean runs that dont error on archived repositories. I feel like it should be pretty simple:

• Dont update repos when the archive flag is set to true however keep them in state

[nickfloyd]

Restating what I understand the core issue to be - basically when users archive a GitHub repository, the provider attempts to delete managed resources (like issue labels -as in the case above) during terraform destroy or resource removal, but fails with a 403 error because archived repositories are read-only.

🤷‍♂️ Solution: Update resourceGithubIssueLabelsDelete and resourceGithubIssueLabelDelete for http.StatusForbidden if a 403 presents itself and the message contains archived then log and no op.

This keeps the repo and it's labels in state without erroring. I feel like this "solution" could become a bit sprawling because there are varied entities hanging off of repo. These were some of the resources that are tied to repos:

• github_actions_secret
• github_actions_variable
• github_dependabot_secret
• github_codespaces_secret
• github_repository_deploy_key
• github_repository_webhook
• github_branch
• github_repository_file (mentioned above)

I think we should write a repo util that would essentially do this check so that it could easily be extended into other repo resource concerns since archive seems to be a state that only impacts repos and it's child resources.

Note: what is being suggested is technically a BREAKING CHANGE given there was one behavior (error being thrown when trying to interact with an archived repo) and now it will log and no op. Though it could be argued that it follows our provider's design principles of idempotency and gracefully handling errors.

[nickfloyd]

This is what I was thinking: https://github.com/integrations/terraform-provider-github/pull/2837

I'm not sure it will matter but I need to think through the behavior of when users "unarchive" repos. I think it should work as expected - given the check will now return false (i.e. the repo is not archived). The only consideration is that whatever was manipulated in the provider state would have changed but not the resource fetched from the API.