feat: region auto-discovery and simplified gitops configuration

[michikrug]

Type of Change

• Bugfix
• Enhancement / new feature
• Refactoring
• Documentation

Description

Problem

Every service repo must explicitly list each region in its gitops-prod (and gitops-dev, gitops-stage) inputs:

gitops-prod: |-
  kubernetes/namespaces/my-service/prod/de1/my-service-cr.yaml spec.template.spec.containers.my-service.image
  kubernetes/namespaces/my-service/prod/us1/my-service-cr.yaml spec.template.spec.containers.my-service.image
  kubernetes/namespaces/my-service/prod/au1/my-service-cr.yaml spec.template.spec.containers.my-service.image

Adding a new production region (e.g. xy1) requires touching every single service repo. There are 150+ services.

Solution

Two new inputs enable a much simpler configuration:

• gitops-namespace — the Kubernetes namespace to look up in the GitOps repo
• gitops-updates — the files to update; environment (dev/stage/prod) is derived from GITHUB_REF automatically, replacing the three separate per-env inputs

The action discovers regions at runtime by listing subdirectories of kubernetes/namespaces/<namespace>/<env>/ in the checked-out GitOps repo. Adding a new region to the GitOps repo is all that is needed — zero service repo changes.

The same config now looks like:

gitops-namespace: my-service
gitops-updates: my-service-cr.yaml

Field resolution

The field specifier in gitops-updates is optional and resolved progressively:

Line format	Resolved yq field
my-service-cr.yaml	spec.template.spec.containers.<namespace>.image
my-service-cr.yaml authentication	spec.template.spec.containers.authentication.image
my-service-cr.yaml spec.template.spec.initContainers.migrate.image	used as-is

Region scoping via directory existence

No explicit region-group configuration is needed. A service deployed only to prod/core will only update that directory. A customer-facing service with prod/ab1, prod/cd1, prod/ef1 will update all of them. Adding prod/xy1 to the GitOps repo automatically picks it up for every service using the new format.

Backward compatibility

This change is fully backward compatible on three levels:

1. gitops-updates vs legacy inputs — gitops-dev, gitops-stage, and gitops-prod continue to work exactly as before. gitops-updates takes precedence only when explicitly set.
2. Shorthand vs explicit paths — when gitops-namespace is set, any line starting with kubernetes/ is passed through unchanged. Mixed explicit and shorthand lines in the same input block are supported.
3. External repos / different directory structures — when gitops-namespace is not set, every line passes through unchanged without any shorthand detection. No risk of breakage for users of this action with a non-kubernetes/ GitOps structure.

Checklist

• Write tests
• Make sure all tests pass
• Update documentation
• Review the Contributing Guideline and sign CLA
• Reference relevant issue(s) and close them after merging

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}