Sync multiple directories dynamically

[ejimz]

Describe the bug

We are having some issues trying to apply a specific use case using Flux V1.
We are creating environments dynamically in github using Flux, to do that we have a directory with helm release templates, this directory is called "templates" and we forked the directory to a new one called "ENV-XXX" (XXX is a random string) using github actions, so we can have a environment called "ENV-123", another one called "ENV-456", etc...
this is working fine, but we need to sync the images automatically with ECR (currently we are hardcoding the images name) , we thought about to add multiple .flux.yaml and .flux-patch.yaml files, one for each environment directory but its not working.

Someone knows if its possible with Flux ? can we automate the image updates dynamically with flux for each subdirectory?

Steps to reproduce

1- Create .flux.yaml file in git root /
2- Create templates directory called "templates" with basic helmrelease
3- Install flux
4- Create in git a directory called "ENV-123" with the helmrelease in the directory templates
5- Add a new .flux.yaml and .flux-patch.yaml in ENV-123 directory
6- Upload a new image to ECR in order to check if helmreleases update the images automatically

Expected behavior

to have the env-123 environment updated with the last image uploaded to the repository.

Kubernetes version / Distro / Cloud provider

EKS 1.21

Flux version

Flux Chart 1.11.2

Git provider

github

Container Registry provider

No response

Additional context

No response

Maintenance Acknowledgement

• I am aware of Flux v1's maintenance status

Code of Conduct

• I agree to follow this project's Code of Conduct

[kingdonb]

Hi @ejimz ! Thanks for reporting this issue you had using Flux.

As mentioned in:

• Flux v1 is in maintenance mode #3320

the Flux v1 repo is in maintenance mode, and this means that support for using it must be limited to issues pertaining to migration support, critical bug fixes, and security issues.

I hate to turn you away as it sounds like you're building preview environments, and this is a use case that we want to support.

It's not clear to me what issue you're trying to solve exactly, but what's likely is that if you haven't already attempted to migrate and found issues that stumped you (and I'm interested to hear about them), the issue will change shape and form when you're migrating to Flux v2.

Preview environments are not completely baked, and while I'm certain there are use cases of preview environments already out there in the wild, we do not have one on display in the Flux v2 examples.

[kingdonb]

To be clear, I'm recommending migrating to Flux v2 first to everyone; if there are blockers that prevented you from migrating, we're interested in better understanding those first, and helping you get over them if possible, or making an adjustment to Flux v2 so that it better supports those use cases when necessary.

This use case isn't particularly well supported in either Flux v1 or v2 right now, but since the lion's share of the development effort is focused on Flux v2, that's where a solution is most likely and that's where I'd recommend you focus your efforts as well, because eventually v1 will be EOL'ed and formally shuttered, with no further security updates. Updates about this as more information becomes available will be posted on the Migration Timetable.

[kingdonb]

Thanks again for your interest in Flux. I'm going to close this issue as I have not heard back in a while. 🙇