-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Labels
Description
Obstacle Description
Repository folder structure is created by shell scripts (project-setup.sh) that build GCP folders based on the directory hierarchy. However, the actual infrastructure (projects, services, networks) is provisioned separately via Terraform.
BDD Format:
Given a repository folder structure: teams/kernel/iac/bootstrap/
When the folder hierarchy changes (e.g., teams/people/new-service/iac/bootstrap/)
And the shell bootstrap script runs to create GCP folders
And existing Terraform state points to old folder hierarchy
Then Terraform may attempt to provision into the wrong parent folder
And the repository structure diverges from cloud resource hierarchy
Why It Blocks Progress
The target condition requires repository folder structure to be the authoritative source of truth for cloud resource hierarchy and permissions.
With two separate tools managing hierarchy (shell scripts) and resources (Terraform):
- Drift risk: Repo structure → GCP folders can desynchronize from Terraform resource parents
- No unified validation: Changes to repo structure aren't validated against Terraform state
- Manual reconciliation: Moving or renaming folder-based teams requires coordination across bootstrap scripts, Terraform, and CODEOWNERS
- Partial automation: Shell scripts handle folder creation but can't enforce the relationship between folder changes and Terraform-managed resources
This violates the single-source-of-truth principle—cloud resource hierarchy should mirror repository structure deterministically, not through separate tools that can diverge.
Suggested Experiments
- Audit current Terraform state: map all resources to their parent folders and compare against repo folder structure (identify current drift)
- Design experiment: modify one folder in repo, run bootstrap, then run Terraform—log whether resources stay in correct parent folders
- Investigate Terraform's
parentmodule input patterns—can Terraform modules accept folder path as parameter instead of hard-coded folder IDs? - Prototype: move bootstrap folder hierarchy logic into a Terraform data source or module that reads repo structure via Git API
- Add CI validation: scan repo structure and Terraform state, fail PR if folder structure changes without corresponding Terraform validation
- Evaluate: could a single Terraform "bootstrap" module replace shell scripts while preserving Git-based hierarchy detection?
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Projects
Status
No status