I was toying with the idea to support multiple versions of kubectl and helm pre-baked into the docker image. setup-environments.sh will download the 3 latest major releases of each package and the entrypoint.sh "wrapper" will setup the $PATH based on the selected versions via HELM_VERSION and KUBECTL_VERSION environment variables.
I have included the following versions in this PR:
helm:
v2.14.1
v2.13.1
v2.12.3
kubectl:
v1.14.3
v1.13.7
v1.12.9
use the plugin / image as usual and pass the KUBECTL_VERSION and HELM_VERSION environments according to the supported version list above.
A major drawback of this PR is the increased image size (122MB -> 486MB), therefore I am not that sure if this approach is sane.
If it turns out that I am the only one here with concerns about that image size, I will gladly finish the PR by adding some sanity checks, documentation and refactor the versions to be configured externally.
I think it's worth the cost of the size. Having an easy way to define which versions you want to use is going to increase the flexibility of the plugin 😄
Do not merge, this needs to be discussed.
I was toying with the idea to support multiple versions of
kubectl
andhelm
pre-baked into the docker image.setup-environments.sh
will download the 3 latest major releases of each package and theentrypoint.sh
"wrapper" will setup the$PATH
based on the selected versions viaHELM_VERSION
andKUBECTL_VERSION
environment variables.I have included the following versions in this PR:
helm:
kubectl:
use the plugin / image as usual and pass the
KUBECTL_VERSION
andHELM_VERSION
environments according to the supported version list above.A major drawback of this PR is the increased image size (122MB -> 486MB), therefore I am not that sure if this approach is sane.
If it turns out that I am the only one here with concerns about that image size, I will gladly finish the PR by adding some sanity checks, documentation and refactor the versions to be configured externally.