Piotr Galar

The sync seems to break on refresh in such a scenario. I suspect we're not cleaning up state correctly.

Right now, terraform will happily propose creating team memberships for users who are not org members but that operation would fail on apply.

This would unblock workflow described in https://github.com/orgs/community/discussions/43951 REST API: https://docs.github.com/en/rest/actions/variables?apiVersion=2022-11-28 TODO: - [ ] add support for configuration variables to terraform github provider

Write now, terraform will happily propose creating collaborator relationship with a team, for example, where in fact it would fail on apply.

It's not enough to make plan/comment required. Other plan/* checks should be required too.

1

We could accomplish that by having a catch-all check at the end maybe? plan/comment is not enough because skipped status doesn't block merging. That's really counter-intuitive.

https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment

Automate side-tasks required for repo archiving

1

When a repo gets archived, we want to be able to perform additional tasks like adding a header to the readme for example. GitHub Management has creds to do it....

https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services Might be obsolete if we implement https://github.com/protocol/github-mgmt-template/issues/76

GitHub Management should be able to manage labels in repos. This was requested here - https://github.com/ipfs/github-mgmt/issues/74 - for example

Otherwise, state refresh can fail if it tries to refresh a resource that no longer exists (this is true at least for repositories that were moved to different orgs).