Closed sprankhub closed 2 months ago
Removing it from the terraform config sounds like a sensible way forward.
@sprankhub Yes. I believe solution you proposed will serve the best.
We could also filter repositories by .archived
property in a for loop({ for key, value in ... : key => value if ... }
), but it would require to manually remove github_branch_protection
from state anyway.
https://developer.hashicorp.com/terraform/cli/commands/state/rm
I'm thinking about implementing state rm
to be possible to invoke from a comment similar to how plans work right now, but I need to better refine this idea.
I'd defo go for the state removal.
You could use an expanded spec for conventional commits and then deignate specific keys for actions? Would make the knowledge share for actions maybe a bit easier to share with the team?
I think the solution proposed by @Jakski to just filter out archived repos in a loop is a bit nicer, because it doesn't require two separate PRs to archive a repository. Theoretically, you'd first need to add the archived
property, so that Terraform archives the repository and then, you'd need to remove the configuration from variables.tf
and remove the state, so that it is ignored in the future. We don't need the second step if we just filter out archived repos. I'll send a PR soonish.
This is about https://github.com/mage-os/terraform/actions/runs/9500022004/job/26182150184.
When a repository is archived, and we update some configuration like the branch protection rules, Terraform will try to apply the changes to the archived repository and GitHub will throw an error:
We had a similar issue in #54, but the new issue cannot be fixed in the same way.
My current idea is that we remove the old, archived repository from the Terraform state and from the
variables.tf
file. This way, Terraform might just ignore the existing, archived repository. Would that work, @Jakski?Any other ideas?