Dry-run support

[raffis]

A dry-run feature would be quite useful to have on the ks pipeline. If you deal with big sources a dry-run is something useful (Also if one migrates a source with existing manifests).
Basically if dry-run is enabled just stop before apply or after the validation.

[stefanprodan]

Why not do this in CI with Kubernetes Kind and kustomize build . | kubectl apply -f- --dry-run=client?

[william-salt-cko]

I think we are all trying to avoid giving CI access to our k8s clusters, this is one of the benefits of using Flux and GitOps. Even a read only SA will still have to read secrets when doing a kustomize diff in most use cases.

Currently, we are doing kubectl dry-runs and helm diffs on our machines with bash scripts whilst we migrate to flux2 from flux1 and plain helm.

After that, we need to build something into our CI for staging, which I don't think we will be able to do for production as it will give it access to secrets.

I think my other discussion is related to this too fluxcd/flux2#820

[JaneLiuL]

@raffis I just upload the code can know what will be change for flux
flux-precheck: https://github.com/JaneLiuL/flux-precheck/releases/tag/0.0.1
Welcome that you could use to know what will be change by flux, the result will be like
You can just download the release bin file and run as flux-precheck --kustomizationName=kustomizationname --kustomizationNamespace=namespace

[JaneLiuL]

Why not do this in CI with Kubernetes Kind and kustomize build . | kubectl apply -f- --dry-run=client?
@stefanprodan I think we can use kubectl apply --dry-run, but that only know what will be create or change,
if we want to know what will be delete, it does not support.
So I just write a script to do that part.

[mbrancato]

I think it makes sense here to have a webhook handle this and report status back. Currently, the webhook can get push updates (from GitHub, others) and trigger an internal git pull on the configured branch. But for CI, it makes sense to have Flux checkout a PR branch, do an in-cluster dry run. Ideally, this can report on create, update, and delete along with the details of what will be changing. I think this might require changes to the notifications to allow a process like: PR -> webhook to Flux -> dry run -> notification webhook to GitHub with result. Today, I don't think there is any way to pass data from the initial webhook into the notifications.

[stefanprodan]

There is now a command for this flux diff kustomization that performs a server-side dry-run and outputs a diff.