[yurnov]

Closes #168.

Two commits: the bump the issue asked for, and a scheduled job so the next one does not need a human to notice.

This is the cautious version, where the automation opens a pull request and you merge it. A fully hands-off variant is possible too — test, update and tag without any manual step -- and I would rather you picked than have me assume; see On how much of this to automate below.

chore: bump default kind to v0.33.0 and kubectl to v1.37.0

• DEFAULT_KIND_VERSION: v0.31.0 -> v0.33.0
• DEFAULT_KUBECTL_VERSION: v1.35.0 -> v1.37.0

Updated in kind.sh, action.yml (both the default: and the input description) and README.md, which is all six places the two strings appear. node_image needs no change -- the action has no default of its own and inherits kind's.

kind v0.33.0 defaults to kindest/node:v1.37.0, so v1.37.0 keeps the client and the default node image on the same minor, exactly as the previous pair did.

feat: add weekly workflow to track kind and kubectl releases

EDIT: this commit was dropped, and the branch was forced without it. So, everything below is just historical context

.github/workflows/update-versions.yaml runs hack/update-versions.sh every Monday at 06:00 UTC (and on workflow_dispatch), and opens a pull request when either default has moved.

The interesting part is deciding which kubectl matches a given kind release. Deriving it arithmetically is tempting and does work for the minor -- kind v0.33.0 to 1.37, v0.32.0 to 1.36, v0.31.0 to 1.35, and so on back -- but it breaks on the patch: kind v0.32.0 defaults to v1.36.1 and v0.29.0 to v1.33.1, not .0. So the script reads kind's own constant instead:

1. Resolve the newest kind tag by following the releases/latest redirect. No API call, so no token and no shared-runner rate limit.
2. Read pkg/apis/config/defaults/image.go at that tag and take the kindest/node:vX.Y.Z it pins. This is the value kind itself uses, so it cannot drift from what a user actually gets.
3. Pin kubectl to dl.k8s.io/release/stable-X.Y.txt, the newest patch of that minor. Client and cluster share a minor, which is what the skew policy requires, while the patch is free to differ -- a v1.37.4 kubectl is a supported client for a v1.37.0 cluster.

That last point also means kubectl bumps on its own when a new patch lands in the current minor, without waiting for a kind release.

The script only needs curl and coreutils -- no jq, no third-party action. It refuses to write anything unless both resolved versions look like vX.Y.Z, and after rewriting it re-counts the references in all three files and fails if any of the six did not take, so a partial rewrite cannot land an action.yml whose default: disagrees with its own description.

Re-runs force-push to a single automated/update-versions branch and update the open pull request rather than opening a second one.

On how much of this to automate

What is here is the conservative half: the workflow proposes and a maintainer decides. Every bump still arrives as a pull request that somebody reads and merges, and cutting a release stays a separate manual step.

The other end is possible too, and may be closer to what the issue is really after: let the workflow run the existing Test suite against the bumped tree, commit straight to main once it passes, then tag the release and move v1 so every @v1 consumer picks up the new kind and kubectl without anyone doing anything. That closes the loop properly — the defaults would never be stale, rather than never being stale for more than a week.

I did not build that one, because it changes things that are yours to decide rather than mine:

• It needs the workflow to push to main, so branch protection has to exempt it or it needs a GitHub App token rather than the built-in GITHUB_TOKEN.
• Moving v1 automatically means a kind or Kubernetes release reaches every consumer of this action with no human in the loop. That is the point of it, but an upstream regression would travel just as fast.
• Releases are cut by hand today, and main currently carries five commits that are not in v1.14.0, so a tag triggered by a version bump would also ship whatever else has landed since the last release. "Bump the defaults" and "cut a release" are not quite the same decision right now.
• Every release so far has been a minor (v1.10.0 through v1.14.0), so there is a question of whether an automated default bump should mint one at all.

There is also an in-between: auto-merge the generated pull request once Test passes, but leave releases manual. That one still needs the token change described below, since Test does not currently run on a pull request the built-in token opened.

Happy to rework this pull request into whichever shape you prefer — just say which, and I will update this branch rather than opening a second pull request.

Notes for reviewers

Worth knowing before merging: pull requests opened with the default GITHUB_TOKEN do not trigger on: pull_request workflows, so Test will not run automatically on the generated pull request. Pushing a commit to the branch, or closing and reopening it, runs the suite. If you would rather it ran unattended, the fix is a PAT or a GitHub App token in place of GH_TOKEN — I left it on the built-in token because that needs no secret and no decision from me.

DEFAULT_CLOUD_PROVIDER_KIND_VERSION is also behind (0.6.0, upstream is at v0.11.1) and is not touched here, since it is outside what #168 asked for and its constant is stored without the v prefix, so the script would need a special case. Happy to do it in a separate pull request if you want it, either as a plain bump or wired into the same workflow.

I have not verified the workflow end to end, since a scheduled workflow that opens pull requests can only really be exercised on the repository itself. The script half is tested: run against the pre-bump tree it reproduces the first commit byte for byte, against the post-bump tree it reports no change and writes nothing, it bumps kubectl alone when only the patch has moved, and it exits non-zero when a reference fails to rewrite.

AI Usage Disclosure

• AI tools were used to assist in this PR.

[yurnov]

Rebased and pushed with --force-with-lease to add Signed-off-by that was missed into commit message

[yurnov]

Hi @cpanato, may I ask you to have this PR reviewed?

[cpanato]

can you drop this job, we dont want this for now

[yurnov]

Sure, will do in the second

[yurnov]

removed

[cpanato]

thanks