What is recommended way to run integration tests after deployment?

[moises-perez-tfs]

I am currently deploying third-party helm charts via Flux2's HelmRelease (CRD). While I can activate helm tests declaratively, the reallity is that some charts have very simplistic helm tests (if any).

It seems I cannot add helm tests to an already existing helm chart. I would have to create a wrapper chart just to add my own tests. I would like to avoid that.

I was wondering what would be the Flux2 way to run integration/stress tests for cases like this one, or applications using kustomize (Kustomizations).

According to the Jenkins + Flux use case documentation:

When adopting Flux’s approach to GitOps, Jenkins should not kubectl apply your manifests anymore. Jenkins does not need direct access to any production clusters.

What is Flux's recommended way to run integration/stress tests without using kubectl apply in a Jenkins pipeline?

[stefanprodan]

You could define your tests in Git as Kubernetes Job manifests, then create a dedicated Flux Kustomization for them by enabling .spec.force. After the HelmRelease rollout you could change an immutable field in your jobs, such as the container tag or some pod label and commit that. Flux will recreate the jobs and run your tests, to get notifications about failed tests you could use .spec.healthChecks.

[gberche-orange]

@stefanprodan would there be a way to automate the process of injecting a mutation in a Job 's spec field to force its recreation and execution, e.g injecting the value of a HelmRelease.status.lastAppliedRevision ? I tried to look at the alternatives below without luck yet.

• Kustomize controller support for variable substitution documents only ConfigMap and Secrets as variable sources. This would not allow to inject HelmRelease.status.lastAppliedRevision as a substituted variable.

• I also briefly looked into whether the Image Update Automation could be abused to write back to the git repo the HelmRelease.status.lastAppliedRevision, but so far I only found OCI-image related source events.

• Likewise, I did not find a way to abuse the Notification Controller into reacting to the cluster changes to reinject a potential the HelmRelease.status.lastAppliedRevision from an event into a Job spec.