unkin/argocd-apps
3
0
Fork 0
Code Issues 7 Pull Requests 7 Actions Packages Projects Releases Wiki Activity

Pin helm capabilities version to the validation target #472

Open
unkin-agent wants to merge 3 commits from benvin/kubeconform-helm-kubeversion into main
pull from: benvin/kubeconform-helm-kubeversion
merge into: unkin:main
Conversation 2 Commits 3 Files Changed 6
+16 -12
unkin-agent commented 2026-09-19 12:28:25 +10:00
Member
Copy Link
Copy Source

Helm renders charts using its own binary default for Capabilities.KubeVersion, which is now v1.36 locally. The rancher 2.13.1 chart constrains kubeVersion to < 1.35.0-0, so kustomize build --enable-helm failed on apps/overlays/au-syd1/cattle-system and, being the first failure under set -e, masked every later overlay.

  • add ci/kube-version as the single source for the Kubernetes target, set to the cluster's 1.33.13
  • read it in ci/validate-apps.sh and ci/validate-clusters.sh for kubeconform
  • pass it as --helm-kube-version on every kustomize build, including make build
  • point AGENTS.md and migration.md at it instead of a hardcoded version
Helm renders charts using its own binary default for Capabilities.KubeVersion, which is now v1.36 locally. The rancher 2.13.1 chart constrains kubeVersion to < 1.35.0-0, so `kustomize build --enable-helm` failed on apps/overlays/au-syd1/cattle-system and, being the first failure under set -e, masked every later overlay. - add ci/kube-version as the single source for the Kubernetes target, set to the cluster's 1.33.13 - read it in ci/validate-apps.sh and ci/validate-clusters.sh for kubeconform - pass it as --helm-kube-version on every kustomize build, including make build - point AGENTS.md and migration.md at it instead of a hardcoded version
unkin-agent commented 2026-09-19 12:33:08 +10:00
Author
Member
Copy Link
Copy Source
  • AGENTS.md:218 — Current Kubernetes target version: **1.33.7** is a second hardcoded copy of the value the PR just made a single source → replace the literal with a pointer to ci/kube-version.
  • AGENTS.md:25,28,121, migration.md:52,53 — the documented render commands are still bare kustomize build --enable-helm <overlay>, so following the docs reproduces the exact cattle-system kubeVersion failure this PR fixes → add --helm-kube-version (or point them at make build).
  • nit: Makefile:3 — $(shell cat ci/kube-version) is cwd-relative and unguarded; if it cannot be read, KUBE_VERSION is empty and the target path is consumed as the flag value (--helm-kube-version clusters/au-syd1/bootstrap --output ...), so kustomize silently builds . instead of erroring → resolve via the makefile dir and fail on empty.
  • nit: ci/validate-apps.sh:4-5, ci/validate-clusters.sh:4-5 — REPO_ROOT anchors only the version file; SCHEMA_DIR=schemas (line 7) and find apps/overlays/find clusters (line 26) are still cwd-relative, so the scripts still only work from the repo root → anchor all of them or drop REPO_ROOT and just cat ci/kube-version.
  • nit: ci/kube-version:1 — 1.33.7, but the live cluster serves v1.33.13 and ArgoCD renders kustomize+helm with the destination cluster version, so CI validates a different Capabilities.KubeVersion than the deploy path → sync to the running version.
  • nit: ci/validate-apps.sh:14-26 — the masking called out in the PR body is untouched; set -e still aborts the loop on the first failing overlay → collect failures and exit non-zero at the end if that behaviour was meant to go.
- `AGENTS.md:218` — `Current Kubernetes target version: **1.33.7**` is a second hardcoded copy of the value the PR just made a single source → replace the literal with a pointer to `ci/kube-version`. - `AGENTS.md:25,28,121`, `migration.md:52,53` — the documented render commands are still bare `kustomize build --enable-helm <overlay>`, so following the docs reproduces the exact cattle-system kubeVersion failure this PR fixes → add `--helm-kube-version` (or point them at `make build`). - nit: `Makefile:3` — `$(shell cat ci/kube-version)` is cwd-relative and unguarded; if it cannot be read, `KUBE_VERSION` is empty and the target path is consumed as the flag value (`--helm-kube-version clusters/au-syd1/bootstrap --output ...`), so kustomize silently builds `.` instead of erroring → resolve via the makefile dir and fail on empty. - nit: `ci/validate-apps.sh:4-5`, `ci/validate-clusters.sh:4-5` — `REPO_ROOT` anchors only the version file; `SCHEMA_DIR=schemas` (line 7) and `find apps/overlays`/`find clusters` (line 26) are still cwd-relative, so the scripts still only work from the repo root → anchor all of them or drop `REPO_ROOT` and just `cat ci/kube-version`. - nit: `ci/kube-version:1` — `1.33.7`, but the live cluster serves `v1.33.13` and ArgoCD renders kustomize+helm with the destination cluster version, so CI validates a different `Capabilities.KubeVersion` than the deploy path → sync to the running version. - nit: `ci/validate-apps.sh:14-26` — the masking called out in the PR body is untouched; `set -e` still aborts the loop on the first failing overlay → collect failures and exit non-zero at the end if that behaviour was meant to go.
unkin-agent commented 2026-09-19 12:46:38 +10:00
Author
Member
Copy Link
Copy Source
  • nit: Makefile:3-4 — anchoring only ci/kube-version to MAKEFILE_DIR leaves every other path in the file cwd-relative (ci/validate-apps.sh/ci/validate-clusters.sh L21-22, ci/generate-schemas.sh L17, manifests/ L12), so make -f /path/to/Makefile kubeconform from another directory now reads the version fine and then dies with ci/validate-apps.sh: No such file or directory → anchor those paths to MAKEFILE_DIR too, or drop it and keep the Makefile repo-root-only like the ci scripts.
  • nit: Makefile:5-7 — the guard is a parse-time $(error), so it also aborts targets that never need the version (make clean, make schemas) → move the check into the build recipe.
- nit: `Makefile:3-4` — anchoring only `ci/kube-version` to `MAKEFILE_DIR` leaves every other path in the file cwd-relative (`ci/validate-apps.sh`/`ci/validate-clusters.sh` L21-22, `ci/generate-schemas.sh` L17, `manifests/` L12), so `make -f /path/to/Makefile kubeconform` from another directory now reads the version fine and then dies with `ci/validate-apps.sh: No such file or directory` → anchor those paths to `MAKEFILE_DIR` too, or drop it and keep the Makefile repo-root-only like the ci scripts. - nit: `Makefile:5-7` — the guard is a parse-time `$(error)`, so it also aborts targets that never need the version (`make clean`, `make schemas`) → move the check into the `build` recipe.
unkin-agent added 3 commits 2026-09-24 23:20:27 +10:00
Pin helm capabilities version to the validation target fb458ea90e 
Render charts with --helm-kube-version from ci/kube-version so kustomize
no longer inherits the local helm binary's default Kubernetes version.
Harden kube-version lookup and match the live cluster 1d77e8c970
Check kube-version inside the build recipe
ci/woodpecker/pr/vector-test Pipeline was successful
Details
ci/woodpecker/pr/pre-commit Pipeline was successful
Details
ci/woodpecker/pr/kubeconform Pipeline was successful
Details
004343437a
unkin-agent force-pushed benvin/kubeconform-helm-kubeversion from 4a66973653 to 004343437a 2026-09-24 23:20:27 +10:00 Compare
All checks were successful
ci/woodpecker/pr/vector-test Pipeline was successful
Details
ci/woodpecker/pr/pre-commit Pipeline was successful
Required
Details
ci/woodpecker/pr/kubeconform Pipeline was successful
Required
Details
Checking for merge conflicts…
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin benvin/kubeconform-helm-kubeversion:benvin/kubeconform-helm-kubeversion
git checkout benvin/kubeconform-helm-kubeversion
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
benvin (BenVincent) unkin-agent (Unkin Agent) unkinben (Ben Vincent)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: unkin/argocd-apps#472
Delete Branch "benvin/kubeconform-helm-kubeversion"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?