Possibility of supporting multiple ref > tags in flux gitrepository objects

[rscafidi]

I've run into a scenario where it would be extremely handy if the gitrepository object was able to "watch" multiple tag references for changes. Right now, based on the docs, it appears that you can only watch one tag. This feature to watch a tag as opposed to a branch is extremely handy for how we do deploys and I'd like to expand on it. I realize this might seem odd or maybe I am abusing the true purpose of flux, but I'll elaborate on my use case to hopefully explain why I'm trying to do this.

We have multiple environment clusters (dev, stage, prod). Each cluster uses FluxCD to manage deployments for all our apps. Apps use Helm Releases. The git repository is a helm chart. When we run our initial pipeline to configure stuff on the infrastructure side, we pass an environment flag that then is used to create Flux gitrepository objects. The git repository object is configured to watch a specific tag for each app and environment. In our dev environment, each app has its own unique tag, and in our staging and prod environment, we have a single tag that all apps use.

For example:
App1 has its own helm release and gitrepository object and is configured to watch a tag in the helm chart repository "App1-dev" for the dev cluster, "staging" for the staging cluster and "prod" for the prod cluster. When we run a CI pipeline, the pipeline retags these tags to kick off a deployment. For stage, it takes the latest deployed in dev. For prod, it takes whatever stage is pointing at.

This works great except in one scenario. Many apps have their own helm chart repository and we can use a single tag per cluster, but one app follows a mono-repo setup where there are actually a dozen "apps" that all share the same helm chart repository but are deployed as individual apps with slight differences, and this is the source of the complexity I'm trying to deal with. To allow for individual deployments for these dozen apps, I've had to use unique dev tags (e.g. App1-dev as above) so that when a developer wants to deploy the app they're working on (that shares the helm chart with other apps), it does not affect all the other apps. This works but it has the drawback that if someone wants to deploy all of the apps, they can't...or they could but would have to run the pipeline multiple times for each unique tag. I've implemented an individual pipeline for this scenario that iterates through all of the tags and retags them to the user's branch the pipeline is running under, but it would be much cleaner if flux was able to watch multiple tags and take the most recently changed tag. This way I could configure one tag for individual deploys and another tag for "all" app deploys. And Flux would use the most recently changed tag to trigger a deployment to the cluster.

A timestamp of a tag in git can be retrieved with git log -1 --format %ai <tag name> so theoretically the gitrepository could be evaluating these times for each tag and switch between whichever tag is the newest (or perhaps there's an even better way).