Repositories

Every repository that makes up the platform — what each one holds, why it exists, and how it is used. They separate cleanly into the cloud foundation, shared modules/charts, and the applications that run on top.

Platform & infrastructure

u2i-gcp-infrastructure ↗

What: Foundation Terraform (managed with Terramate): the GCP org hierarchy, projects, GKE Fleet, networking, and the per-app CI/CD scaffolding.
Why: It is the single source of truth for the cloud foundation — every project, cluster, and pipeline exists because it is declared here.
Usage: Register a new app by adding an entry under foundation/4-tenants/terramate.tm.hcl; apply with terramate run -- terraform apply. app-cicd.tf then generates the app's triggers, service accounts, registries, and Cloud Deploy pipelines.

u2i-infra ↗

What: The tenant infrastructure reconciled onto the clusters by Config Sync: namespaces, Workload Identity bindings, and GCS buckets per app.
Why: Keeps in-cluster infrastructure declarative and GitOps-managed, separate from application workloads and from the cloud foundation.
Usage: Add a subchart under chart/charts/apps/ and enable it in k8s/{env}/rootsync.yaml. Config Sync continuously applies it to the u2i-nonprod / u2i-prod clusters.

Shared modules & charts

terraform-google-compliance-modules ↗

What: Reusable Terraform modules aligned with ISO 27001 / SOC 2 Type II — zero-standing-privilege IAM, PAM entitlements, organization policies, CMEK helpers.
Why: Encapsulates the compliance controls so every project inherits the same audited baseline instead of re-implementing it.
Usage: Consumed as module sources by u2i-gcp-infrastructure. Versioned; the foundation pins specific module versions.

gke-tenant-charts ↗

What: The shared Helm charts: gke-tenant-foundation (namespaces, Gateway, RBAC), gke-tenant-workload (ServiceAccount + Workload Identity, ExternalSecrets, KEDA), gke-tenant-storage (GCS buckets via Config Connector), gke-tenant-alloydb.
Why: Gives every app a consistent, reviewed deployment surface — apps declare intent and inherit platform conventions rather than hand-rolling manifests.
Usage: Each chart is versioned independently (foundation, workload, storage, alloydb each have their own line — there is no shared version sequence). Publishing runs on the GitHub Actions release workflow — NOT Cloud Build, and NOT on merge to main (a merge only runs lint). The tag NAME is the release: it alone selects which chart is packaged and at what version, so a wrong name publishes the wrong chart or fails — and each chart bumps on its own semver (patch = template fix, minor = additive field e.g. dns.publicZone.records was 0.6.4→0.7.0, major = breaking change). The workflow helm-pushes just that one chart to oci://europe-west1-docker.pkg.dev/u2i-bootstrap/helm-charts, keylessly via Workload Identity Federation. Consumers pin a version in their Chart.yaml dependencies. Two ways to cut a release:

Option 1 — push a tag (recommended)

git checkout main && git pull
git tag gke-tenant-foundation-0.7.1
git push origin gke-tenant-foundation-0.7.1

Option 2 — manual workflow dispatch

gh workflow run release.yaml --repo u2i/gke-tenant-charts \
  -f chart=gke-tenant-foundation -f version=0.7.1

Check what's actually published

gcloud artifacts docker tags list \
  europe-west1-docker.pkg.dev/u2i-bootstrap/helm-charts/gke-tenant-foundation \
  --project u2i-bootstrap

build-lib ↗

What: The shared Cloud Build engine: a Docker image (Nushell + gcloud/kubectl/helm/crane/buildx) plus a Nushell library of typed commands (build image, release package-for-config-sync, kube login, …).
Why: Keeps every app's CI/CD pipeline short and identical — the real build logic lives in one versioned place instead of being copy-pasted as bash across repos.
Usage: App deploy/cloudbuild/*.yaml run the build-lib image with the init-step/build-step wrappers and pin a version tag. See the build-lib page.

Applications

retrotool ↗

What: The RetroTool app (Meteor / Node.js). Carries its workload Helm chart, Cloud Build pipelines, Skaffold config, and Dockerfile.
Why: The canonical reference deployment on the platform — the worked example used throughout this documentation.
Usage: Push to main deploys to dev; a version tag promotes through qa to prod; PRs get preview environments. See the Example page.

retrotool-landing-page ↗

What: The public marketing / landing site for RetroTool.
Why: Separates the marketing surface from the product application and its release cadence.
Usage: Deployed on the platform as its own tenant app, following the same CI/CD pattern.

compensation ↗

What: An Elixir application running as a tenant on the platform.
Why: Demonstrates the platform is language-agnostic — the same foundation, charts, and pipelines host non-Node.js stacks.
Usage: Registered in the foundation like any other app; ships its own Helm chart depending on the shared workload chart.

compliance-demo ↗

What: A JavaScript demo application showcasing the compliance platform end to end.
Why: A reference / showcase used to validate and demonstrate the compliance controls in a running app.
Usage: Deployed on the platform; exercises the same registration, secrets, and rollout flow.