Cheat notes · Module 01 · Platform foundation

Your fleet repo and the change workflow

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

Protect the process before you build anything. One bootstrap commit brings CI, issue forms and review rules; from then on main only accepts pull requests that pass validate and plan, starting with the cluster inventory.

Remember

One bootstrap commit: an empty repo cannot receive a pull request, so .github/ and scripts/ go in with one direct push. It is the only direct push in the course.
Required checks: validate runs scripts/validate.sh (YAML, schemas, references, ownership, policies, Terraform). plan comments which Argo CD Applications the change adds, removes or re-targets.
Branch protection: require a pull request, require validate and plan, and do not allow bypassing, so it applies to the owner too. Allow squash merging only: one commit per change keeps reverts simple.
CODEOWNERS: maps folders to owners. The platform team owns everything by default; product teams own their deployment folders.
The production environment with required reviewers is how prod approvals work later (production-gate).
The inventory clusters/*.yaml is the single source of truth for which clusters exist. Terraform and every ApplicationSet read it.

Pitfalls

Copying an API address from your own kubeconfig into the inventory (https://127.0.0.1:6443). validate fails and merge stays blocked: the hub needs an address it can reach, https://dev-control-plane:6443.
Forgetting scripts/set-repo-url.sh after a copy: manifests still point at the reference repo and pushes "do nothing". fleet_check.py now fails on it.
The required checks only appear in the branch rule after they have run once: come back after the first pull request.

Commands

`git remote add reference https://github.com/platformengr/fleet-gitops.git && git fetch reference`	The finished fleet as a second remote, to copy from
`git checkout reference/main -- FOLDER`	Bring one folder from the reference into your branch
`scripts/set-repo-url.sh`	Point copied files at your repo (`--codeowners @you` the first time)
`scripts/validate.sh`	Run CI's checks locally
`python3 scripts/fleet_check.py`	Inventory and fleet checks; lists the Applications the fleet would contain

Test yourself

Answer in your head first, then open the answer.

Why does the bootstrap commit bring .github/ and scripts/ before any manifest?

So every later change, starting with the inventory, is validated and reviewed.

What does the plan check add on top of validate?

A comment saying which Argo CD Applications the change adds, removes or re-targets: the effect on the fleet, not just a YAML diff.

Where do you add a third cluster?

A new file in clusters/, through a pull request.

Where module 01 leaves you: A repo with CI, issue forms and review rules; main only accepts pull requests that pass validate and plan; and clusters/dev.yaml and clusters/prod.yaml merged through that process. No cluster exists yet.