Git repo watching: Watch changes on a tag, fallback to a branch if the tag does not exist.

[OndraZizka]

Hi. We have a setup:

• App source code repo, and
• k8s setup repo.

Most of the K8s setup is shared, and then there are some parametrizations per environment.
FluxCD watches the K8s repo tags, one per environment, and applies the changes to the respective cluster.

We would like to change this to observe a branch main, so that any push to that branch would be picked up (applied).

However, sometimes, we would like to hold that behavior for experiments on the shared K8s setup, and/or deploy a test environment from another branch, by pinning a tag.

For that, it would be great if FluxCD could be configured to:

• Apply what is pinned with a tag for a given cluster;
• If the tag is deleted, then apply the branch.

Currently, AFAIK, it can only be either a branch, OR a tag.

Which means:

• Either we have a lot of tags shuffling overhead,
• Or it is not so easy to apply different shared K8s setup to different environments.

1. Is there currently a way to solve that elegantly?
2. If not, is the proposed feature (a fallback from a tag to a branch) considerable for implementation?

Thanks.

[stefanprodan]

A fallback from a tag to a branch is not something I would consider doing in Flux. Git tags should be immutable, you don't delete tags, instead you would increment semver and move forward with a new tag.

Take a look at Ephemeral Environments for GitHub Pull Requests
this would allow you to run experiments from PRs on your test cluster.

[OndraZizka]

I got you. I did not invent this, the company ditched semver and moves tags. Actually it's quite a trend. If you have a coherent system, you do not really have versions, you rather have a history of states where things work together.

That said:

Moving a tag in Git is quite standard operation. The claim that Git tags should be immutable is subjective at best. If they should be immutable, then there would be no git tag -f <name>.

FluxCD allows to observe a tag, and apply when the tag changes. Another hint that tags are meant to move - what would be the point of this feature otherwise?

So, the only step missing is to put a 2nd entry into FluxCD config (a fallback branch), and apply the branch tag disappears.

[matheuscscp]

The feature of referencing a tag is for giving you the ability to reference tags, there's no underlying assumptions of tags moving. Also I never heard of this approach of moving Git tags before, every single experience I had with Git tags was with them being immutable.

[stefanprodan]

However, sometimes, we would like to hold that behavior for experiments on the shared K8s setup, and/or deploy a test environment from another branch, by pinning a tag.

Instead of having a fallback in Flux from tag to branch, you could configure the canary cluster to follow a branch e.g. test. Experiments go to test, once they are deemed Ok, you merge test into main promoting the change to all clusters.