Feature: helm test

[hazcod]

Is support for the helm test cli command already baked in, or would a test = true be a nice addition?

[jwenz723]

Seems like this would be most useful if the helm_release resource had an attribute to enable the execution of helm test after the helm_release has been created or updated since the test suite is always directly related to a particular release.

My current workaround for achieving the execution of helm test after each release revision is:

Define a kubeconfig template:

apiVersion: v1
preferences: {}
kind: Config

clusters:
- cluster:
    server: ${endpoint}
    certificate-authority-data: ${cluster_auth_base64}
  name: this

contexts:
- context:
    cluster: this
    user: this
  name: this

current-context: this

users:
- name: this
  user:
    token: ${user_token}

Define a helm_resource to release the helm chart, define a kubeconfig local which makes use of the template above, define a null_resource which downloads the helm binary and configures it to use the generated kubeconfig then execute helm test:

data "aws_eks_cluster" "cluster" {
  name = var.cluster_name
}

data "aws_eks_cluster_auth" "cluster" {
  name = var.cluster_name
}

resource "helm_release" "gocolor" {
  name             = "gocolor"
  namespace        = "gocolor"
  create_namespace = true
  chart            = "gocolor"
  version          = var.helm_chart_version
  repository       = "https://jwenz723.github.io/gocolor"
  //  atomic = true
  wait            = true
  cleanup_on_fail = true

  values = [<<EOF
gocolorEnv:
  account: jwenz723
  color: blue
  region: ${var.region}
EOF
  ]
}

resource "null_resource" "helm_test_gocolor" {
  triggers = {
    name       = helm_release.gocolor.name
    namespace  = helm_release.gocolor.namespace
    repository = helm_release.gocolor.repository
    values     = jsonencode(helm_release.gocolor.values)
    version    = var.helm_chart_version
  }

  depends_on = [helm_release.gocolor]

  provisioner "local-exec" {
    environment = {
      // Placing these values in the environment to prevent them from being logged
      KUBECONFIG = local.kubeconfig
    }
    command = <<EOF
curl -LJO https://get.helm.sh/helm-v3.4.1-linux-amd64.tar.gz &&
tar -zxvf helm-v3.4.1-linux-amd64.tar.gz &&
mv linux-amd64/helm ./helm &&
echo "$KUBECONFIG" > ./kubeconfig
chmod 611 ./kubeconfig
export KUBECONFIG=./kubeconfig
./helm test -n ${helm_release.gocolor.namespace} ${helm_release.gocolor.name}
EOF
  }
}

locals {
  kubeconfig = templatefile("${path.module}/kubeconfig.tpl", {
    endpoint            = data.aws_eks_cluster.cluster.endpoint
    cluster_auth_base64 = data.aws_eks_cluster.cluster.certificate_authority.0.data
    user_token          = data.aws_eks_cluster_auth.cluster.token
  })
}

[github-actions[bot]]

Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!

[Illidanek]

It seems like this is a basic feature that is missing from the provider.

Either a flag like @hazcod suggested or perhaps even better: a helm_test resource which would allow more granular control over which tests run when.

[github-actions[bot]]

Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!

[hazcod]

Unstale

[ccrockatt]

We have crossplane resources that we apply via a helm chart and setting wait = true does not work for it because the resources aren't any of the standard kinds such as jobs or deployments etc. Having the test functionality would allow us to verify that those resources were deployed successfully.