action-setup-kube-tools

July 5, 2026 · View on GitHub

action-setup-kube-tools

A GitHub Action that setup Kubernetes tools (kubectl, kustomize, helm, kubeconform, conftest, yq, rancher, tilt, skaffold, kube-score) and cache them on the runner. It is like a typescript version of stefanprodan/kube-tools with no command input param, but as compared with it, it's very fast as it installs the tools asynchronously.

Note

This repository enforces immutable releases — published release tags and assets cannot be modified or deleted, ensuring supply chain integrity.

Usage

Inputs

Parameter	Required	Default Value	Description
`fail-fast`	`false`	`true`	the action immediately fails when it fails to download (ie. due to a bad version)
`arch-type`	`false`	`""`	Optional. The processor architecture type of the tool binary to setup. The action will auto-detect the architecture (`amd64` or `arm64`) and use it as appropriate at runtime. Specify the architecture type (`amd64` or `arm64`) only if you need to force it.
`setup-tools`	`false`	`""`	List of tool name to setup. By default, the action download and setup all supported Kubernetes tools. By specifying `setup-tools` you can choose which tools the action setup. Supported separator is `return` in multi-line string. Supported tools are `kubectl`, `kustomize`, `helm`, `kubeval`, `kubeconform`, `conftest`, `yq`, `rancher`, `tilt`, `skaffold`, `kube-score`
`version-file`	`false`	`""`	Optional. Path to a `.tool-versions` (asdf/mise) style file. For each supported tool with an entry in the file, that version is used unless the tool's own version input is explicitly set. Resolution order: explicit tool input > `version-file` entry > built-in default. Each line is `<tool> <version>`; `#` comments, blank lines, and unsupported tool names are ignored. See Using a version file.
`kubectl`	`false`	`1.35.3`	kubectl version or `latest`. kubectl versions can be found here
`kustomize`	`false`	`5.8.1`	kustomize version or `latest`. kustomize versions can be found here
`helm`	`false`	`3.20.1`	helm version or `latest`. helm versions can be found here
`kubeval`	`false`	`0.16.1`	kubeval version (must be 0.16.1+) or `latest`. kubeval versions can be found here. NOTE: this parameter is deprecating as `kubeval` is no longer maintained. A good replacement is kubeconform. See also this for more details.
`kubeconform`	`false`	`0.7.0`	kubeconform version or `latest`. kubeconform versions can be found here
`conftest`	`false`	`0.67.1`	conftest version or `latest`. conftest versions can be found here
`yq`	`false`	`4.52.5`	yq version or `latest`. yq versions can be found here
`rancher`	`false`	`2.13.3`	Rancher CLI version or `latest`. Rancher CLI versions can be found here
`tilt`	`false`	`0.37.0`	Tilt version or `latest`. Tilt versions can be found here
`skaffold`	`false`	`2.18.1`	Skaffold version or `latest`. Skaffold versions can be found here
`kube-score`	`false`	`1.20.0`	kube-score version or `latest`. kube-score versions can be found here

Note

Supported Environments: Linux
From v0.7.0, the action supports tool version 'v' prefix. Prior to v0.7.0, the action only accept the tool version without 'v' prefix but from v0.7.0 the action automatically add/remove the prefix as necessary
From v0.13.X, the action supports latest as tool version. If a tool input is set to latest, the action resolves the latest version at runtime, then downloads and caches that exact version. However, using latest can make builds non-reproducible, as the installed version may change over time. For stable and repeatable builds, it is recommended to specify exact versions

Outputs

Parameter	Description
`kubectl-path`	kubectl command path if the action setup the tool, otherwise empty string
`kustomize-path`	kustomize command path if the action setup the tool, otherwise empty string
`helm-path`	helm command path if the action setup the tool, otherwise empty string
`kubeval-path`	kubeval command path if the action setup the tool, otherwise empty string
`kubeconform-path`	kubeconform command path if the action setup the tool, otherwise empty string
`conftest-path`	conftest command path if the action setup the tool, otherwise empty string
`yq-path`	yq command path if the action setup the tool, otherwise empty string
`rancher-path`	rancher command path if the action setup the tool, otherwise empty string
`tilt-path`	rancher command path if the action setup the tool, otherwise empty string
`skaffold-path`	rancher command path if the action setup the tool, otherwise empty string
`kube-score-path:`	rancher command path if the action setup the tool, otherwise empty string

Sample Workflow

Pinned versions (reproducible):

  test: 
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: yokawasa/action-setup-kube-tools@v0.13.5
      with:
        kubectl: '1.35.3'
        kustomize: '5.8.1'
        helm: '3.20.1'
        kubeconform: '0.7.0'
        conftest: '0.67.1'
        rancher: '2.13.3'
        tilt: '0.37.0'
        skaffold: '2.18.1'
        kube-score: '1.20.0'
    - run: |
        kubectl version --client
        kustomize version
        helm version
        kubeconform -v
        conftest --version
        yq --version
        rancher --version
        tilt version
        skaffold version
        kube-score version

Default versions for the commands will be setup if you don't give any inputs like this:

  test: 
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: yokawasa/action-setup-kube-tools@v0.13.5
    - run: |
        kubectl version --client
        kustomize version
        helm version
        kubeconform -v
        conftest --version
        yq --version
        rancher --version
        tilt version
        skaffold version
        kube-score version

By specifying setup-tools you can choose which tools the action setup. Supported separator is return in multi-line string like this

  test: 
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: yokawasa/action-setup-kube-tools@v0.13.5
      with:
        setup-tools: |
          kubectl
          helm
          kustomize
          skaffold
        kubectl: '1.25'
        helm: '3.11.1'
        kustomize: '5.0.0'
        skaffold: '2.1.0'
    - run: |
        kubectl version --client
        kustomize version
        helm version
        skaffold version

Architecture is automatically detected on the runner (amd64 or arm64). You can optionally force it by specifying arch-type: 'amd64' or arch-type: 'arm64'.

  test: 
    steps:
    - uses: actions/checkout@v4
    - uses: yokawasa/action-setup-kube-tools@v0.13.5
      with:
        # arch-type is optional; uncomment to force arm64
        # arch-type: 'arm64'
        setup-tools: |
          kubectl
          helm
          kustomize
          skaffold
        kubectl: '1.25'
        helm: '3.11.1'
        kustomize: '5.0.0'
        skaffold: '2.1.0'
    - run: |
        kubectl version --client
        kustomize version
        helm version
        skaffold version

Explicit latest inputs (optional):

  test: 
    steps:
    - uses: actions/checkout@v4
    - uses: yokawasa/action-setup-kube-tools@v0.13.5
      with:
        # arch-type is optional; uncomment to force arm64
        # arch-type: 'arm64'
        setup-tools: |
          kubectl
          helm
          kustomize
          skaffold
        kubectl: latest
        helm: latest
        kustomize: latest
        skaffold: latest
    - run: |
        kubectl version --client
        kustomize version
        helm version
        skaffold version

Note: Using latest makes builds non-reproducible since versions can change over time. Prefer pinning exact versions for stability.

Using a version file

If you already pin tool versions in a .tool-versions file (the asdf/mise format), point version-file at it instead of repeating each version in the workflow:

# .tool-versions
kubectl 1.30.0
helm 3.14.4
kustomize 5.4.0
# unsupported tools and comments are ignored
nodejs 20.0.0

  test:
    steps:
    - uses: actions/checkout@v4
    - uses: yokawasa/action-setup-kube-tools@v0.13.5
      with:
        version-file: '.tool-versions'
    - run: |
        kubectl version --client
        helm version
        kustomize version

A tool's own version input always overrides its version-file entry, so you can pin most versions in the file and selectively override one in the workflow:

  test:
    steps:
    - uses: actions/checkout@v4
    - uses: yokawasa/action-setup-kube-tools@v0.13.5
      with:
        version-file: '.tool-versions'
        # kubectl from .tool-versions is overridden here; helm/kustomize still come from the file
        kubectl: '1.31.0'

Resolution order is: explicit tool input > version-file entry > built-in default. Tools without an entry in the file (and without an explicit input) fall back to their built-in default version.

A version-file entry may also be set to latest (e.g. kubectl latest), in which case the action resolves the latest version at runtime, just like the latest tool input. Note that using latest makes builds non-reproducible since versions can change over time; prefer pinning exact versions for stability.

Developing the action

Install the dependencies

npm install

Build the typescript and package it for distribution by running ncc

npm run build && npm run format && npm run lint && npm run pack

Finally push the results

git add dist
git commit -a -m "prod dependencies"
git push origin releases/v0.13.X

action-setup-kube-tools

action-setup-kube-tools

Usage

Inputs

Outputs

Sample Workflow

Using a version file

Developing the action

References

Contributing

Changelog