Helm tests are a useful validation mechanism for Helm Releases, and thus are supported by the Helm Operator.
When tests for a HelmRelease
are enabled, the Helm Operator will run them
after any successful installation or upgrade attempt. In the case of a test
failure, the prior installation or upgrade will be treated as failed, resulting
in the release being purged or rolled back if enabled.
Tests can be enabled by setting .test.enable
:
spec:
test:
enable: true
When tests are enabled, resource waiting
defaults to true
since this is likely needed for test pre-conditions to be satisfied.
The spec.test.ignoreFailures
allows the HelmRelease
to be left in a released state if the tests fail.
Setting ignoreFailures
to false
will automatically uninstall or rollback the HelmRelease
if any of the tests fail.
If the tests are ignored, the Released
condition will be left as true
and Tested
will be false
.
spec:
test:
enable: true
ignoreFailures: false
Test timeout can be set via the .test.timeout
option.
spec:
test:
enable: true
timeout: 600
It is defined as the time to wait for any individual Kubernetes operation during
tests in seconds. Defaults to 300
when omitted.
In Helm 3, test-specific funcationality was removed in favor of a generic test
hook no different than any other hook. The Helm Operator takes this into account
as detailed below.
Helm 3 removed the helm test --cleanup
flag in favor of hook delete policies.
For HelmRelease
s targeting Helm 2, test cleanup is enabled by default since
upgrades are highly likely to cause test pod name conflicts without it.
This flag currently deletes test pods immediately after they are run, but the only
guarantee is that tests are cleaned up before running a subsequent test for the
same HelmRelease
, as delaying the deletion would allow time to debug failures,
and thus may be implemented in the future. Test cleanup can be disabled by setting
.test.cleanup
to false
.
spec:
helmVersion: v2
test:
enable: true
cleanup: false
Helm 2 supported helm test --parallel --max 10
to run tests in parallel. Helm 3 will
likely expand this functionality to all hooks. Once the Helm 3 implementation is available
this can be integrated into the Helm Operator, and translated into the equivalent
Helm 2 options for test parallelism as well.