This guide explains how to contribute to the Spin Helm recipes with minimal friction. Keep changes small, tested, and documented so others can reproduce them.
nats/: Helm values and kustomize post-renderer for the NATS chart;values.yamlfor defaults andtls-acme-values.yamlfor certificate setup.kustomize/patches StatefulSets/Deployments withSPIN_UID/SPIN_GID.tls-acme/: Standalone Helm chart (Chart.yaml,templates/,values.yaml) for ACME-driven TLS issuance and renewals on Spin.scripts/: Utility scripts (e.g.,scripts/mdl.shfor markdownlint autofix).- Repo configs:
.pre-commit-config.yaml,.yamllint.yml,.markdownlint.rbdefine lint rules; align contributions to them.
pre-commit run --all-filesto run markdownlint, yamllint, and trailing whitespace checks locally.yamllint .to validate YAML with the repo config (line length 120, strict indentation)../scripts/mdl.shto autofix Markdown formatting before review.helm lint tls-acmeto sanity-check the TLS chart; add-f <values>as needed.- For NATS overlays, render and patch locally:
cd nats/kustomize && helm template nats/nats -f ../values.yaml --post-renderer ./kustomize.sh.
- YAML: 2-space indentation, descriptive keys, keep
*-values.yamlfile names and placeholder tokens (RUN_AS_USER_PLACEHOLDER,FS_GROUP_PLACEHOLDER) intact for scripted substitution. - Markdown: respect
.markdownlint.rb(ordered lists, generous line length). Prefer short headings and actionable steps. - Shell: keep scripts POSIX/Bash compatible, check for required env vars (
SPIN_UID,SPIN_GID) before use.
- Chart changes: run
helm lintand, when altering templates,helm template ... | kubectl kustomize ./nats/kustomizeto verify patches apply cleanly. - Functional checks occur on Spin: follow the per-directory READMEs to install/upgrade releases, then validate via
kubectlexecs (e.g.,nats rtt) or ingress reachability. - Add brief notes in PRs on what was verified (commands + namespace/cluster used), especially for TLS issuance runs.
- Commits: imperative mood with scope when helpful (e.g.,
nats: adjust websocket ingress whitelist); group related changes. - PRs: include a summary of changes, linked issues (if any), values files touched, commands run, and relevant logs or screenshots for install/upgrade attempts.
- Avoid committing secrets or cluster-specific kubeconfigs; keep sensitive values in local overrides and document placeholders instead.