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

References

• https://kubernetes.io/releases/
• https://github.com/kubernetes-sigs/kustomize/releases
• https://github.com/helm/helm/releases
• https://helm.sh/docs/topics/version_skew/
• https://github.com/instrumenta/kubeval/releases
• https://github.com/open-policy-agent/conftest/releases
• https://github.com/mikefarah/yq/releases
• https://github.com/rancher/cli/releases
• https://github.com/tilt-dev/tilt/releases
• https://github.com/GoogleContainerTools/skaffold/releases
• https://github.com/zegl/kube-score/releases

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/yokawasa/action-setup-kube-tools

Changelog

Please see the list of releases for information on changes between releases.