ci: gate template PRs on the deploy/ scaffold building#3
Merged
Conversation
The deploy/ Kustomize manifests are this template's core deliverable — every new tenant inherits them — yet nothing in the template repo's own CI verified they still build. A PR that broke the kustomization (a renamed/removed resource, a YAML error) could merge green and ship broken manifests to every new tenant; the README only documented `kubectl kustomize deploy/` as a manual local step. Add a template-repo-only `validate-scaffold.yaml` that renders `deploy/` on every PR (the same command the README documents). It is guarded with `if: github.repository == 'devantler-tech/gitops-tenant-template'`, so it no-ops in tenants created from the template — symmetric to how cd.yaml/ release.yaml run only in tenants and skip in the template. Actions are hash-pinned (zizmor-clean) and the runner is harden-runner-fronted, matching portfolio convention. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds a lightweight CI gate to ensure the template repository’s core deploy/ Kustomize scaffold continues to render successfully on pull requests, preventing broken scaffolds from being shipped to new tenants.
Changes:
- Introduces a new GitHub Actions workflow that runs
kubectl kustomize deploy/on PRs tomain, guarded to run only indevantler-tech/gitops-tenant-template. - Updates the README’s “Owned by the template” table to include the new workflow.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
README.md |
Documents the new scaffold-validation workflow as template-owned. |
.github/workflows/validate-scaffold.yaml |
Adds a PR workflow that renders deploy/ via Kustomize (template-repo only) to catch broken scaffolds early. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The Validate Scaffold job only reads the repo to run `kubectl kustomize deploy/` and never pushes, so the checkout does not need to keep the GITHUB_TOKEN. Setting persist-credentials: false resolves the zizmor / code-scanning credential-persistence (artipacked) finding that left PR #3 BLOCKED on an unresolved review thread. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
deploy/Kustomize manifests are this template's core deliverable — every new tenant created from the template inherits them as its startingdeploy/. Yet nothing in the template repo's own CI verified the scaffold still builds. A PR that broke the kustomization (a renamed or removed resource, a YAML error) could merge green and ship broken manifests downstream to every new tenant. The README only documentedkubectl kustomize deploy/as a manual, local check — easy to skip.Change
Add
.github/workflows/validate-scaffold.yaml— a small scaffold-integrity gate that runskubectl kustomize deploy/on every PR (the same command the README documents;kubectlwith embedded kustomize is preinstalled onubuntu-latest, so no cluster or CRDs are needed — it just renders the manifests to catch a broken kustomization).if: github.repository == 'devantler-tech/gitops-tenant-template', so it no-ops in tenants created from the template — symmetric to howcd.yaml/release.yamluse the inverse guard to run only in tenants and skip in the template repo. Tenants replacedeploy/with their own app and validate it via their own (owned)ci.yaml.unpinned-uses-clean), the runner isharden-runner-fronted, top-levelpermissions: {}with a minimalcontents: readon the job — matching portfolio standards.Validation
kubectl kustomize deploy/→ renders 6 resources OK locally (the exact CI command).actionlint→ clean.Trade-off for the maintainer to weigh (the reason this is a draft)
Because the file is template-owned, template-sync carries it into tenants, where it shows as a perpetually-skipped workflow run (the guard is false there). This is symmetric to
cd.yamlbeing perpetually skipped in the template repo (which ships no app), so it follows an already-accepted pattern — but it is mild extra noise in tenant PR checks. If you'd rather keep scaffold validation local-only (status quo), close this; if you promote it, consider adding theValidate Scaffoldcheck to the branch ruleset's required-status-checks so it actually blocks merges (a ruleset change is yours to make).