# Validate Kubernetes Manifests in CI

Yes. An agent adds kubeconform and kube-linter checks over your Kustomize and Helm renders, records findings, and opens a pull request without editing manifests.

[Run this on Rush](https://cloud.getrush.ai/run/write-manifest-tests/kubernetes/), in a Project that has your repository.

## What the agent does

The agent inventories how the app is packaged. In GoogleCloudPlatform/microservices-demo (Online Boutique) it finds plain manifests under `kubernetes-manifests/` (adservice, cartservice, checkoutservice, currencyservice, emailservice, frontend, loadgenerator, paymentservice, productcatalogservice and more), a Kustomize tree at `kustomize/` with `base/`, many `components/` (network-policies, service-mesh-istio, spanner, memorystore, …) and `kustomize/tests/` combinations, plus `helm-chart/` (`Chart.yaml` name `onlineboutique`) with templates for the same services.

It reads existing CI so new checks fit. `.github/workflows/kustomize-build-ci.yaml` only runs `kubectl kustomize` / `kustomize build` on base and `kustomize/tests/*`. `.github/workflows/helm-chart-ci.yaml` runs `helm lint --strict` and `helm template` then `kustomize build` on the rendered YAML. Neither workflow installs kubeconform nor kube-linter today, and `kubevious-manifests-ci.yaml` is a different static pass. The agent does not rewrite service YAML to silence policies.

It adds a script (for example `scripts/validate-manifests.sh`) that (1) builds `kustomize/` base and each `kustomize/tests/*` overlay, (2) runs `helm template` from `helm-chart/` into a temp file, and (3) pipes every render through `kubeconform` against upstream Kubernetes schemas and `kube-linter` with checks for missing liveness/readiness probes, resource limits/requests and `securityContext`. Findings are written to a markdown or text artifact in the branch (or the pull request body) instead of auto-fixing Deployment specs.

It wires the script into a workflow step beside the existing kustomize/helm jobs (or extends those workflows), runs the script in the sandbox so the first push shows the current finding list, and opens a pull request that contains only the script, workflow glue and the findings report. The script enumerates service YAMLs the same way a human would: every file under `kubernetes-manifests/` that the base kustomization references, each overlay directory returned by `ls -d kustomize/tests/*/`, and `helm template .` from `helm-chart/` including the grpc health and spanner value sets the existing helm-chart-ci job already exercises, so findings mention which render path produced each object.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Add a test script and CI step that renders every Kustomize component and the Helm chart in this repository and validates the output with kubeconform against the Kubernetes schemas and with kube-linter for missing probes, limits and securityContext. Fix nothing in the manifests; open a pull request with the checks and their current findings.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-microservices"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request that adds the validation script, a CI workflow step, and a checked-in findings list for the current renders. Files under `kubernetes-manifests/`, `kustomize/**/`.yaml service patches and `helm-chart/templates/` are not modified, matching the prompt.

The pull request description summarises how many objects kubeconform accepted and which kube-linter checks reported issues (for example missing probes on a named Deployment). The trajectory keeps the install lines for kubeconform and kube-linter and the full command output from each render path.

Before merging, a reviewer confirms the script covers base, `kustomize/tests` and `helm template`, that schema versions match the cluster version the team runs, and that failing lint rules are ones the team wants visible. Turning findings into manifest fixes is a separate follow-up request.

## Run it on every manifest or Helm template changed

On pull requests that touch `kubernetes-manifests/`, `kustomize/` or `helm-chart/`, POST this session body so the agent refreshes the findings report in a dedicated branch. That keeps schema drift visible without asking a human to run kubeconform locally.

Subscribe the API key webhook to `run.completed` and forward the session URL to the platform channel. Use `max_concurrent` to avoid overlapping full-repo renders when many manifest PRs land together.

## Why run it on Rush?

Rendering every Kustomize component plus the Helm chart is a multi-minute, tool-heavy job (kustomize, helm, kubeconform, kube-linter). Rush runs it in a sandbox with those binaries installed, so your laptop is not tied up downloading schemas or fighting plugin versions.

Because the agent is forbidden to "fix" manifests, the pull request is an honest safety net: CI fails or reports on policy gaps while service YAML stays reviewably unchanged. Several services or overlays can be validated in parallel across runs.

## Frequently asked questions

### Will it change my Deployments to add probes?

No. The prompt says fix nothing in the manifests. It records kube-linter findings in the pull request so humans can prioritise remediations.

### Does this replace the existing kustomize-build-ci job?

It extends the story: build still proves overlays render; the new step proves rendered objects match schemas and policy checks. The agent prefers adding a step or sibling workflow over deleting `kustomize-build-ci.yaml`.

### Which Kubernetes version are the schemas for?

The agent pins a kubeconform schema version in the script (aligned with whatever the README or deploy docs claim, or a current stable if the repo is silent) and states that pin in the pull request. Adjust the pin in review if your clusters differ.

### Are Istio or Spanner overlays included?

Yes, insofar as they appear under `kustomize/components/` and `kustomize/tests/`. The script loops those test folders the same way `kustomize-build-ci.yaml` already does.