This repo pins tool versions in shell scripts, PowerShell, and capz templates. Nothing updates them, and nothing tells you they're stale. Dependabot is configured, but only for the github-actions ecosystem — it can't see a version string inside run-capz-e2e.sh.
So the pins age quietly until they show up in an incident writeup:
Current inventory of pins Dependabot can't see:
| Pin |
Where |
Datasource |
containerd v1.7.16 |
capz/run-capz-e2e.sh |
github-releases |
Helm v3.15.2 |
capz/run-capz-e2e.sh |
github-releases |
Azure CLI 2.76.0 |
scripts/ci-k8s-common.sh |
github-releases |
pause:3.10.2 |
4+ files under capz/templates/ |
docker registry |
Win32-OpenSSH v9.5.0.0p1-Beta |
#585, if it lands |
github-releases |
It's not a long list, but every entry is load-bearing for CI.
Two deliberate exclusions: KUBERNETES_VERSION in run-capz-e2e.sh (moves the tested Kubernetes version on purpose — that's a human decision) and the legacy job-templates/*.json (containerd 1.6.0 / azure-vnet-cni 1.4.13 for k8s 1.23/1.24 — frozen, leave them be).
Proposal: updatecli
updatecli does exactly this job: one small manifest per pin, each declaring a datasource (GitHub release, docker tag) and the file locations to patch. A weekly scheduled workflow runs updatecli apply and opens one PR per stale pin. Schedule it right after Dependabot's Monday wave, so a maintainer triages every dependency PR in a single pass.
I run this setup in another repo (workflow: https://github.com/karlkfi/github-actions-gateway/blob/main/.github/workflows/updatecli.yml, manifests under updatecli.d/) for the same class of pins Dependabot can't see — kind, Calico, shellcheck, buildkit, envtest. Porting it here is mostly copy-paste plus the manifest table above.
One caveat before anyone types /lgtm: the workflow's GITHUB_TOKEN can only open PRs if the repo setting "Allow GitHub Actions to create and approve pull requests" is enabled, and for kubernetes-sigs repos that's managed through org tooling. It's a one-time ask, but it's a real prerequisite — no point merging the workflow without it.
If OWNERS want this, I'll send the PR.
/sig windows
/sig testing
/kind feature
This repo pins tool versions in shell scripts, PowerShell, and capz templates. Nothing updates them, and nothing tells you they're stale. Dependabot is configured, but only for the
github-actionsecosystem — it can't see a version string insiderun-capz-e2e.sh.So the pins age quietly until they show up in an incident writeup:
v1.7.16incapz/run-capz-e2e.shwas the "one pinned moving part" that [Failing Test] Windows e2e node CPUManager specs failing since 2026-07-17 (windows-e2e-node-master) kubernetes/kubernetes#140777 had to rule out during the CPUManager regression hunt.Current inventory of pins Dependabot can't see:
v1.7.16capz/run-capz-e2e.shv3.15.2capz/run-capz-e2e.sh2.76.0scripts/ci-k8s-common.shpause:3.10.2capz/templates/v9.5.0.0p1-BetaIt's not a long list, but every entry is load-bearing for CI.
Two deliberate exclusions:
KUBERNETES_VERSIONinrun-capz-e2e.sh(moves the tested Kubernetes version on purpose — that's a human decision) and the legacyjob-templates/*.json(containerd 1.6.0 / azure-vnet-cni 1.4.13 for k8s 1.23/1.24 — frozen, leave them be).Proposal: updatecli
updatecli does exactly this job: one small manifest per pin, each declaring a datasource (GitHub release, docker tag) and the file locations to patch. A weekly scheduled workflow runs
updatecli applyand opens one PR per stale pin. Schedule it right after Dependabot's Monday wave, so a maintainer triages every dependency PR in a single pass.I run this setup in another repo (workflow: https://github.com/karlkfi/github-actions-gateway/blob/main/.github/workflows/updatecli.yml, manifests under
updatecli.d/) for the same class of pins Dependabot can't see — kind, Calico, shellcheck, buildkit, envtest. Porting it here is mostly copy-paste plus the manifest table above.One caveat before anyone types
/lgtm: the workflow'sGITHUB_TOKENcan only open PRs if the repo setting "Allow GitHub Actions to create and approve pull requests" is enabled, and for kubernetes-sigs repos that's managed through org tooling. It's a one-time ask, but it's a real prerequisite — no point merging the workflow without it.If OWNERS want this, I'll send the PR.
/sig windows
/sig testing
/kind feature