Didn't see any changes after running ci-mock.sh?

[ZillaG]

I ran the following command, keeping in mind to use my dockerhub username, and it did push a Docker image with a dev-xxxx tag. What's supposed to happen isn't clear after that.

cd hack && ./ci-mock.sh -r zillag/podinfo -b dev

The walkthrough says

With the fluxcd.io/automated annotations I instruct Flux to automate this release. When a new tag with the prefix dev is pushed to Docker Hub, Flux will update the image field in the yaml file, will commit and push the change to Git and finally will apply the change on the cluster.

Some questions:

• Should I create the dev (and stg later) branch first before running the mock script? (I did anyway.)
• Should I expect the releases/dev/podinfo.yaml to change in my local repo, and pushed to my remote? IOW, I'm not clear about the interaction between my local files, Git remote, and Kubernetes. There were no steps outlined on what I should check after I run the mock script.

[hiddeco]

A very strong advise to stop looking into the Helm Operator and continue to look at the helm-controller (and Flux v2 in general), as both Flux v1 and the Helm Operator are in maintenance mode.

Some starter points on automated Helm releases with Flux2:

• https://toolkit.fluxcd.io
• https://toolkit.fluxcd.io/get-started/
• https://toolkit.fluxcd.io/guides/helmreleases/
• https://github.com/fluxcd/flux2-kustomize-helm-example

[ZillaG]

I'll heed your advise, thanks. In the meantime, is the README.md information in the repo obsolete now? This is my first foray into helm+flux, and although I understand the concept, I'm just now developing my experience.

[hiddeco]

In the meantime, is the README.md information in the repo obsolete now? This is my first foray into helm+flux, and although I understand the concept, I'm just now developing my experience.

It is for Flux2, as this was build from the ground up. The Flux2 version of doing things is covered in: https://github.com/fluxcd/flux2-kustomize-helm-example (and https://github.com/fluxcd/flux2-multi-tenancy for multi-tenancy).

We are planning on archiving this repository in the near future to make it more obvious, as we did for the other examples.