Yes, probably, if you’re building a re-usable component that will be used from multiple other repositories in your organization. If your organization will only be consuming it from exactly one other repository, then I would move it into that repository rather than keeping it in a separate Git repository.
Indeed - by which I mean, the repository is already a module by itself, so there should be zero module blocks contained within it.
resource "github_organization_settings" "organization_settings" {
# I'm not sure about the for_each in this block, your code is a
# bit indecisive about whether it configures one organization
# or multiple organizations.
...
}
resource "github_membership" "organization_memberships" {
for_each = ...
...
}
resource "github_team" "all" {
for_each = ...
...
}
resource "github_team_membership" "members" {
for_each = ...
...
}
In this design, the github_team_membership for_each expression will be a bit complicated, as it needs to flatten looping over both teams, and members within those teams. There is a fairly standard, if complicated, Terraform idiom for this, which I recently gave an example of here: Attach multiple policy to single SSO permission set - #2 by maxb and it is also mentioned in a slightly different form in the Terraform docs: https://developer.hashicorp.com/terraform/language/functions/flatten#flattening-nested-structures-for-for_each
There is a potential alternative design in which the github_team and github_team_membership resources are moved into a child module (one
module, not separate team and a team-membership modules), so that looping over teams can be done at the module for_each, and looping over members at the resource "github_team_membership" for_each. It is a matter of personal preference regarding Terraform code style as to which design is used.