Provide a latest tag on docker images

[gavinclarkeuk]

It would be useful to have a latest tag on docker images of the latest stable release. My use case is specifically for the cli, but probably makes sense for all the images.

We use CI to run flux diffs against PRs, and also to upgrade flux on our clusters each week. To ensure we are on the latest flux client version we have to install it as part of our CI pipeline, but it would be much cleaner to just use the flux cli docker image. Because there isn't a latest tag, switching to the docker image would mean constantly updating our build scripts when a new release comes out.

[stefanprodan]

We provide a script for installing the latest CLI and a GitHub Action, both fetch the latest version using the GitHub releases API. You could use one of two options or adapt your CI job to get latest for GitHub.

[gavinclarkeuk]

I'll try the install script - we're currently using a mac agent and homebrew on CircleCI (mainly due to laziness on my part) which works fine. I was just trying to avoid doing the install every time. I'll have a play with the install script and some workspace caching and see if that is any quicker.

I think it would still be useful to have a latest image tag, but is very much a nice to have.

[kingdonb]

I think in general the Flux project takes a stance against latest tags because they are impractical for a lot of Flux-specific use cases. I was looking for the FAQ entry about it, but all it talks about is how the timestamps must be present in the string tag in order to facilitate image update automation (which isn't really relevant here.)

Should we keep this open, or close as wontfix?

[kingdonb]

The Flux github action provides a model for how to download the latest flux; I think that caching is the right idea, if you can put a check for cache between this line:

https://github.com/fluxcd/flux2/blob/e09078f6979fb97d255e4b2178611de7d6f7553d/action/action.yml#L28

and this line:

https://github.com/fluxcd/flux2/blob/e09078f6979fb97d255e4b2178611de7d6f7553d/action/action.yml#L32

it will prevent you from a lot of unnecessary time spent downloading again.

Take care though, that you are paying attention to the version that your clusters are on. If this is used in a CI pipeline where a bare kind cluster is created with no Flux on it, and then the flux binary is used to install, that's fine. If the flux binary is being used to target an existing cluster for some action, only same<->same version is expected at this interface. You must use the same version of flux cli to interact with a cluster that has been used to install flux on it (unless you are in the process of upgrading.)

As far as upgrading Flux, I recommend using the GitHub Action or equivalent to upgrade. This link (GitHub Action) the same that Stefan provided shows how you can install Flux CLI, how you can open a PR when there is a new version of Flux, and let the maintainer of your cluster merge the PR when it's time to apply the upgrades.

It would be good to add some cache awareness here, honestly I don't know how caching works on GitHub Actions from end to end. It depends a lot on whether you use a hosted runner or not. Most of this is probably not relevant on CircleCI.

You might want to review the changelog before upgrading Flux, since sometimes there are breaking changes. Another good solution that also works on GitHub Actions is Renovate, which will detect Flux installations in your cluster and upgrade them similarly to the Flux github action, but also delivering a link to any relevant CHANGELOG details with the PR.