scripts/

scripts/

Shell helpers used by developers and by Makefile targets. Everything here is meant to be runnable from the repo root. Authoritative behaviour lives in the scripts themselves — run with --help where supported.

start-dev-env.sh

Manages a Kind-based local development environment. Subcommands:

up --skip-build and restart --skip-build reuse an existing controller image instead of rebuilding (handy when iterating on chart-only changes). status uses source-hash.sh to show whether the cluster is running your latest code — always run it before debugging.

test-templates.sh

Runs the validation tests embedded in the chart's libraries. Equivalent to:

1. helm template charts/haptic … (with --api-versions for Gateway API)
2. Extract the single HAProxyTemplateConfig with yq
3. haptic-controller validate -f <merged>.yaml [--test <name>] [--dump-rendered] [--verbose]

./scripts/test-templates.sh                                   # all tests
./scripts/test-templates.sh --test test-httproute-basic       # one test
./scripts/test-templates.sh --dump-rendered --verbose         # debug failing test
./scripts/test-templates.sh --output yaml | yq '.tests[].name'  # list available tests

Always prefer this over running haptic-controller validate against a library file directly — library files are incomplete (no haproxyConfig, no cross-library snippets) and will fail validation on their own.

test-helm-defaults.sh

Renders the chart with default values and asserts key invariants — useful as a quick "does the chart still produce valid output after my change?" check. Runs in CI on every MR.

test-benchmark.sh

Wrapper around go test -bench=... that picks the right -count, -benchtime, and -run defaults for this project's benchmarks, and teeing output to a file for comparison.

generate-dev-ssl-cert.sh

Generates a self-signed SSL certificate plus matching key for the dev environment. Called automatically by start-dev-env.sh; rarely run directly.

source-hash.sh

Emits a short hash of all *.go files under pkg/ and cmd/. start-dev-env.sh status uses it to decide whether the controller running in the dev cluster matches local source. Deterministic — same tree produces the same hash across runs.

extract-dataplane-spec.sh

Downloads the OpenAPI v3 specification for a given HAProxy Dataplane API version by spinning up a throwaway Docker container, querying /v3/specification_openapiv3, and saving the response as formatted JSON.

./scripts/extract-dataplane-spec.sh 3.2
./scripts/extract-dataplane-spec.sh 3.1 /tmp/dataplane-v31.json
./scripts/extract-dataplane-spec.sh 3.0 pkg/generated/dataplaneapi/v30/spec.json

Requirements: Docker, curl, jq, nc. The script handles container lifecycle itself — if you see cleanup errors, remove the container manually with docker rm -f dataplaneapi-extract-<version>.

Used for code generation — after saving a new spec, run make generate-dataplaneapi-v<version> to regenerate the typed Go client under pkg/generated/dataplaneapi/.

fetch-k8s-openapi-schemas.sh

Refreshes the K8s built-in schemas under tests/schemas/ from a running cluster. These power offline typed-watched-resources access (controller validate --schema-dir tests/schemas) for the K8s built-ins the chart watches alongside its CRDs — Namespace, Service, Secret, ConfigMap, EndpointSlice, Ingress. Run when the kube-apiserver version bumps or when adding a new K8s built-in to the bundle.

# Uses KUBE_CONTEXT (defaults to kind-haptic-e2e); needs `kubectl` reachable.
./scripts/fetch-k8s-openapi-schemas.sh

The script queries each resource's /openapi/v3/... endpoint, inlines $refs into the schema, and emits a CRD-wrapped YAML file per resource (tests/schemas/<group>_<version>_<resourcePlural>.yaml). The CRD wrapper is what lets pkg/k8s/schemafetcher/dir_fetcher.go::PluralsFor resolve (apiVersion, plural) → GVK offline — bare OpenAPI v3 files with an x-kubernetes-group-version-kind extension work for typed lookup but don't register a plural, so chart configs declaring watchedResources.<X>: { apiVersion: v1, resources: <X> } couldn't resolve their GVK without it.

Requirements: a kube context with the resources installed (kind clusters are fine — the OpenAPI surface is identical across vanilla apiserver builds), kubectl, python3, and yq.

release.sh

Invoked by make release RELEASE_VERSION=... (which runs release.sh <version>). One invocation prepares the whole release (controller + chart share one version): it promotes the CHANGELOG.md [Unreleased] section, bumps VERSION and Chart.yaml (version, appVersion, image annotations), updates the helm install --version examples and the docs-site changelog copies, and creates the release commit. Do not call it directly in normal workflows — go through the Makefile target so you get the arg validation for free. See docs/controller/docs/development/releasing.md for the end-to-end release process.

See Also

• Makefile — the authoritative list of developer commands; most of these scripts are accessible as make <target>
• docs/controller/docs/development/releasing.md — release process
• charts/CLAUDE.md — chart development workflow (test-templates.sh is the recommended entry point)