docs(qa): catalog base64-corrupted infra YAML defect pattern (GRO-2699)

2026-08-09 11:17:17 +00:00
parent e5b175601c
commit 74203073f4
@@ -0,0 +1,29 @@
# Defect Pattern: Infra YAML Corrupted to Single-Line Base64 Blob
**Owner:** QA (Lint Roller) · **First cataloged:** GRO-2699 (infra PR #732) · Previously seen on a corrupted `ci.yml`.
## Symptom
A `groombook/infra` PR that should be a trivial edit (e.g. an image tag bump) shows a huge `deletions` count and `additions: 1` per file. The diff replaces the entire original YAML with a **single line of base64 text**, ending with `\ No newline at end of file`. The base64, when decoded, is the *correct intended YAML* — so the change looks right at a glance and the PR body reads normally.
## Why it's dangerous
- The file **content on disk is literally the base64 string**, not YAML. `kustomize build` parses it as a single scalar, not a Kustomization → **Flux fails to reconcile the entire overlay**, not just the intended change. On a prod overlay this can wedge prod GitOps.
- A reviewer skimming the *rendered* diff may mentally decode the base64 and approve the correct-looking intent, missing that the on-disk bytes are broken.
## Detection (do this on every infra PR)
1. **Trust CI red.** The infra `CI / ci` YAML-lint step fails (exit 1) on the corrupted files. Never wave a red infra PR through.
2. **Confirm the raw bytes** via the Gitea contents API — decode **once**:
- Healthy: decodes to `apiVersion: kustomize...` (real YAML).
- Corrupted: decodes to *another* base64 string (e.g. `YXBpVmVyc2lvbjog...`).
3. Watch for the diff shape: single `+` line + `\ No newline at end of file` + a deletion count matching the whole original file.
## Fix
Re-commit each affected file as **plain YAML text** (the decoded content), then confirm CI is green. Fast local self-check: `kustomize build apps/overlays/<env>`.
## Related
- QA defect-pattern catalog: see also *dev-uat Promotion Clobbers Env-Specific Overlay State* and *kubeconform CI Flake*.
- Root cause is a tooling/serialization slip on the author side (a file written base64-encoded instead of decoded), not a logic bug — so the *intent* is usually correct; only the encoding is wrong.