I need Guardrails (Gates) Across my deployments which are using fluxcd , Approver section required before going to prod

[zameer712]

I need Guardrails (Gates) Across my deployments which are using fluxcd , Approver section required before going to prod

can somebody please help with an working sample around this scenario

@stefanprodan : FYI if you have any thing handy around this

[stealthybox]

There are some older RFC's around Gates.
Last KubeCon, the Flux team also talked through some alternative styles of "changeGate" API's. (no design docs yet)
The work is non-trivial and won't be done soon.

There are plenty of other ways for you to gate changes in the repos that Flux is using and the clusters themselves through Flux's verious API's that point to refs, tags, and versions.
Please consider using:

• Pull-Requests/Merge-Requests in your git platform of choice
• Building your config into OCIRepositories
• Tagging your repositories
• Versioning charts using Helm OCI
• Using a ConfigMap to set which GitRepository refs are being cloned
• Using Flagger's several lifecycle hooks
• Writing a CronJob to curl your Git Platform, Ticketing, or Change Review system
• Using some other Controller/CRD to pull in information from your ticket system (like JIRA) into the cluster

You will need to define what an "approval" looks like for yourself with your own set of tools, team habits, and etc.
(ex: click a button on a JIRA ticket / comment "/lgtm" on a GitHub PR / send an e-mail that fires a webhook...)

This a general answer for a general question.
If you are looking to accomplish something specific, feel free to provide more detail.

I am confident that Flux already has a lot of the features you need to integrate with your toolset and accomplish what your team is looking for.