Provide hook to instruct Helm operator to refresh git mirrors

[hiddeco]

Fixes #1430

This adds a webhook to the Helm operator as described in the issue above. The webhook starts a goroutine which instructs every mirror to refresh.

[stefanprodan]

I had the impression that fluxctl sync does a git sync and applies the manifests on the cluster. If that's the case I would expect that sync will also trigger helm upgrades for all releases after the git refresh.

[hiddeco]

@stefanprodan this is already how it works, see:

https://github.com/weaveworks/flux/blob/dde522e0bf5a60f510aa4936757ab4d18a68064b/git/mirrors.go#L75
https://github.com/weaveworks/flux/blob/dde522e0bf5a60f510aa4936757ab4d18a68064b/integrations/helm/chartsync/chartsync.go#L159

[squaremo]

Some method of authentication

In general it's desirable to defer to existing means of authentication, i.e., credentials for the Kubernetes API. However that requires either more work on the part of the user (to construct a port forward or proxy) or set up a reverse proxy/ingress (with its own authentication); or a command-line tool for the helm operator, which we don't have.

I guess we could have fluxctl helm notify or some such, which would use the port-forwarding already in fluxctl.

[hiddeco]

I guess we could have fluxctl helm notify or some such, which would use the port-forwarding already in fluxctl.

I am somewhat opposed to this as it tightens the relationship between the 3 tools currently living in this repository.

fluxctl and the daemon already have a strong relationship but with our plans for the operator to actually move away from this repository I am afraid this would be a step into the wrong direction.

[stefanprodan]

I think most users will be happy with:

kubectl -n flux port-forward deployment/flux-helm-operator 3030:3030 &
curl -XPOST http://localhost:3030/api/v1/sync-git

[squaremo]

fluxctl and the daemon already have a strong relationship but with our plans for the operator to actually move away from this repository I am afraid this would be a step into the wrong direction.

Yeah, it is a weak suggestion. Leaving it to people to construct a port-forward themselves is probably acceptable.

[squaremo]

I'm OK with this as it is (OK, maybe with typos excised), but please consider my suggestion in the comments.

[squaremo]

Looks good Hidde 👍