[Jeff-Tian]

Thanks for this great action!

I've been using it with ubuntu-latest GitHub-hosted runners, but recently I needed to run this action with my self-hosted Windows runners, turned out it doesn't support it. I've made some changes to this action, and it's working well now. I hope these changes help others.

You can also verify it first by using:

      - name: Create kind cluster
        uses: Jeff-Tian/kind-action@main
        with:
          cluster_name: your-test

[cpanato]

Thanks for the contribution, @Jeff-Tian! The approach is reasonable and Linux behavior is preserved, but a few things need to be addressed before this can merge.

Blocking

1. Rebase / conflicts. The PR conflicts with main. install_kind and install_kubectl now use the call_curl helper instead of raw curl, so please keep that when resolving.

2. DCO. The DCO check is blocked; please sign off the commit (git commit -s --amend).

3. No coverage for the new paths. CI is green only on ubuntu-latest, so nothing exercises the Windows/macOS code. Please add workflow jobs on macos-* / windows-* runners. Hosted macOS/Windows runners lack Docker (Linux containers), so these would likely need install_only: true and just verify kind version / kubectl version --client.

4. Linux-only paths remain unguarded. These still assume Linux and will fail or misbehave elsewhere:

   • install_cloud_provider (downloads linux_amd64, uses sudo + /usr/local/bin)
   • create_config_with_registry (sudo + /etc/kind-registry)
   • registry.sh (sudo tee -a /etc/hosts)
   • cleanup.sh (/tmp)

   Please either fail early with a clear error when registry/cloud_provider are used on a non-Linux OS, or document them as unsupported.

5. Windows needs verification. RUNNER_TOOL_CACHE is a backslash path on Windows; please confirm the -x checks and the entries written to GITHUB_PATH behave correctly under Git Bash.

6. Architecture mapping. The uname -m mapping is unchanged. Please confirm that arm64 (Apple Silicon) and AMD64 (Windows) resolve to the right release asset names (arm64 / amd64).

Suggestions

• The checksum logic is duplicated between kind and kubectl and is weaker than before (sha256sum -c also validated the filename in the checksum file). Consider a small verify_sha256 <file> <expected> helper, keeping the shasum -a 256 fallback for macOS.
• Clean up trailing whitespace and the redundant local url_os="${os}".
• Add a short README note on supported OSes and the Docker caveat (kind can only create clusters where Docker is available; hosted macOS/Windows runners don't have it).

[Jeff-Tian]

Thanks for the thorough review, @cpanato ! All items are addressed in the latest commit:

Blocking items

1. Rebase / conflicts — Rebased onto main. Both install_kind and install_kubectl now use the call_curl helper as requested.
2. DCO — The commit is now signed off.
3. Coverage for the new paths — Added two CI jobs: test-install-only-macos (macos-latest) and test-install-only-windows (windows-latest), both with install_only: true and verifying kind version / kubectl version --client. One note: kind stopped publishing Windows binaries from v0.33.0 onwards (v0.31/v0.32 shipped kind-windows-amd64), so the Windows job pins version: v0.32.0 with a comment explaining why.
4. Linux-only paths — Added fail-early guards with clear errors:
   • create_kind_cluster in kind.sh errors out when registry / cloud_provider are enabled on a non-Linux OS (this covers install_cloud_provider and create_config_with_registry).
   • registry.sh exits early on non-Linux (covers the /etc/hosts write).
   • cleanup.sh only touches /tmp and cloud-provider files on Linux.
     Also documented as unsupported in the README.
5. Windows verification — RUNNER_TOOL_CACHE backslash paths, the -x checks on kind.exe / kubectl.exe, and the entries written to GITHUB_PATH all work under Git Bash. The new windows-latest CI job will confirm this in practice.
6. Architecture mapping — Extended the uname -m mapping: AMD64 / amd64 / x86_64 → amd64 (Windows), arm64 / AARCH64 / aarch64 / arm → arm64 (Apple Silicon), plus a clear error message for unsupported architectures.

Suggestions

• Added a verify_sha256 <file> <expected> helper (keeping the shasum -a 256 fallback for macOS), used by both install_kind and install_kubectl. For kind, the expected sum is still extracted by grepping the filename from the .sha256sum file, so filename validation is preserved.
• Removed the redundant local url_os and cleaned up trailing whitespace.
• Added a "Supported Operating Systems" section to the README covering the Docker caveat and the install_only: true requirement on hosted macOS/Windows runners.

One extra fix found while testing: the post step (cleanup.sh) would fail on runners without Docker, since kind delete cluster / docker rm error out and fail the job. Registry removal is now gated on Linux, and cluster deletion only runs when both kind and docker are available. Verified locally on macOS (darwin/arm64): install, checksum verification, and post-cleanup all pass end-to-end.

[Jeff-Tian]

Also verified on GitHub Actions (of my own fork) that all checks are green: https://github.com/Jeff-Tian/kind-action/actions/runs/38105508017

[cpanato]

The Windows install-only test pins version: v0.32.0, but the action defaults to v0.33.0 (action.yml). The installer builds the Windows artifact URL from the selected version; as noted above, kind no longer publishes Windows binaries starting with v0.33.0. Therefore, Windows users following the README guidance without setting a version will fail to install. Please either choose a Windows-compatible default/version on Windows or make the required version explicit in the docs, and add coverage for the documented default path.

[cpanato]

Blocking: Windows installation fails when users follow the documented install-only path without specifying a version. The action defaults to kind v0.33.0, but Windows binaries are not published for v0.33.0 or later; the Windows CI job masks this by pinning v0.32.0. Please ensure the default Windows path selects a supported version (or explicitly require/document one) and add coverage for that path.

[Jeff-Tian]

Correction to my earlier note: I re-checked the kind release assets and v0.33.0 does shipkind-windows-amd64 (+ sha256sum) — my claim that Windows binaries were dropped in v0.33.0 was wrong, and it wrongly led to pinning the Windows CI job to v0.32.0.

Apologies for the confusion. The pin is now removed: thewindows-latest job runs with the default version (v0.33.0), which both closes the default-path coverage gap you pointed out and simplifies things. Verified the asset is downloadable and its sha256sum matches.

Updated the test workflow, and verified all checks passed: https://github.com/Jeff-Tian/kind-action/actions/runs/38139034523

[cpanato]

thanks!