Update GitHub Actions to the latest versions - #12

Why

I noticed this as the following workflow run reported this warning:
https://github.com/aboutbits/boilerplate-api/actions/runs/34054228876/job/101543814380?pr=233#step:3:13

Node 20 is being deprecated. This workflow is running with Node 24 by default.
If you need to temporarily use Node 20, you can set ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true environment variable.
For more information see: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/

The blog post says that Node 20 support will be completely removed on September 23rd, 2026,
so aboutbits/github-actions-kubernetes/setup-kubectl-and-helm would have stopped working after that date

setup-kubectl-and-helm is the source.
azure/setup-kubectl@v4 and azure/setup-helm@v4 are the only two actions in this repository that declare the node20 runtime.
Every other action here is already on node24, or it is composite.

Changes

Action versions

Default tool versions

Both inputs stay overridable, so a consumer can pin any other version.

The readme also gets a correction. It documented the input as kube-version, but the action defines kubectl-version.
It also still showed the old default versions.

Breaking change review

I read the release notes of every bumped action. Result: no breaking change affects this repository.

azure/setup-kubectl v4 -> v5

• v5.0.0 moves the runtime from node20 to node24.
• v5.0.0 changes the download domain from cdn.dl.k8s.io to dl.k8s.io. Check any egress allowlist on self-hosted runners. GitHub-hosted runners are not affected.
• v5.0.0 accepts a major.minor input and resolves it to the latest patch of that minor. This PR uses that form. The kubectl section below explains the choice.

azure/setup-helm v4 -> v5

• v5.0.0 moves the runtime from node20 to node24 and migrates the build to ESM.
• No input changed. No behavior changed.

actions/checkout v5 -> v7

• v6.0.0 writes the git credentials to a separate file instead of .git/config. No action in this repository reads .git/config or the auth header, so nothing breaks.
  The input persist-credentials still defaults to true, so git-commit-and-push-all still pushes.
• v7.0.0 blocks the checkout of fork pull request code when the trigger is pull_request_target or workflow_run.
  The new input allow-unsafe-pr-checkout: true opts back in. This release workflow uses workflow_dispatch, so the block does not apply.

Helm v3.17.3 -> v3.21.4

I scanned all 22 intermediate releases: v3.17.4, six v3.18.x, six v3.19.x, three v3.20.x and five v3.21.x.
I checked both the summaries and the full commit changelogs. No breaking change.

• No release marks an entry as breaking, incompatible or removed.
• No flag that this repository uses changed. I checked --atomic, --wait, --history-max, --set-file and --values.
• The HELM_DRIVER: configmaps setting in helm-deploy is unchanged.
• Helm v3 keeps semantic versioning, so a minor release adds no breaking change by policy.

Two more facts:

• v3.21.4 is a security patch release. It fixes several Go CVEs, among them GO-2026-5932 and GO-2026-6061.
• The v3.21.0 note warns that Helm v3 approaches end-of-life and recommends Helm v4. Helm v3.21 bundles the Kubernetes client libraries v1.36.

kubectl v1.33.1 -> v1.36

The new default is v1.36, a major.minor value. Azure/setup-kubectl v5 resolves it to the latest patch of that minor through https://dl.k8s.io/release/stable-1.36.txt, which returns v1.36.4 today.

Why a minor version, and not a full version. The do-cluster module sets auto_upgrade = true and pins cluster_version = "1.35".
The clusters therefore already float their patch version inside a fixed minor. kubectl now follows the same model, and it picks up client patches without a PR.

Why v1.36, and not v1.35. All four clusters run v1.35.7 today, and we upgrade them to v1.36 soon.
The version skew policy supports one minor above the cluster and one below it:

kubectl stays inside the supported window across the whole transition, so the action needs no second bump.

I also checked the Kubernetes v1.36 changelog against the commands that this repository runs, which are apply, rollout status, rollout undo, wait and logs.
No v1.36 client change affects any of them. The v1.36 urgent upgrade notes cover kube-controller-manager metrics and the scheduler framework, so they are server-side only.

Azure/setup-helm offers no equivalent. Its version handling only prepends a v, so a major.minor value such as v3.21 produces a 404.
helm-version therefore keeps a full version.

Follow-up items, not in this PR

1. The sed command in .github/workflows/release.yml rewrites every uses: ...@vN in readme.md. It does not limit the match to aboutbits/ references, so it also overwrites third-party examples.
   github-actions-vercel/readme.md already shows the damage: it documents actions/checkout@v1.
   This repository has no third-party example in its readme yet, so no damage exists here.
2. Helm v4 is out, and the latest release is v4.2.4. Helm v3 approaches end-of-life.
   A v3 to v4 bump is a major version change that can break consumers, so it needs its own PR and its own test round.

Test plan

• Trigger the "Release Package" workflow and confirm that actions/checkout@v7 succeeds.
• Run a consumer workflow that calls setup-kubectl-and-helm and confirm that the Node 20 warning is gone.
• Confirm that kubectl resolves v1.36 to the latest v1.36 patch, and that Helm installs at v3.21.4.
• Run a deployment against a v1.35.7 cluster with kubectl v1.36, and confirm that kubectl apply and kubectl rollout status behave as before.
• Run a helm-deploy against a preview environment, and confirm that helm registry login and helm pull oci:// still work on Helm v3.21.4.

🤖 Generated with Claude Code