Tag multiple separate version streams in a single git repo

[TheEdgeOfRage]

We have a monorepo with several separate services contained within. My intent was the following for managing staging/prod deployments:

1. Merges to main trigger github action build that pushes the built code images to the registry. There would be one
   image for each service
2. Flux image automation picks up the images and updates the manifests on the same repo, for both staging and prod.
3. We then have one Flux kustomization for each service that picks up the manifest changes in main and applies them
   to staging
4. For prod deploys, I want to be able to create a tag like service_a-x.x.x, service_b-x.x.x and only apply the manifest
   changes for the given service, so that we can deploy our services separately.

On the image updates I can define the following:

  filterTags:
    pattern: '^service_a-v(?P<version>.+)$'
    extract: '$version'
  policy:
    semver:
      range: x.x.x

and only detect new images for the given service, but it seems to me that this isn't possible on the GitRepository to be
able to deploy only one service when a tag to github matches a pattern. I've also looked at using OCI artifacts, but
they seem to have the same restriction. Is there any other way to achieve this?

[stefanprodan]

Instead of using Git you can switch to OCIRepository as the source of your apps Flux Kustomizations.

In CI, when you tag Git with service_a-x.y.z, publish an OCI artifact like so:

# parse the git tag and extract $service_name and $service_semver
flux push artifact oci://ghcr.io/org/manifests/${service_name}:${service_semver} \
--path="./" \
--source="$(git config --get remote.origin.url)" \
--revision="$(git tag --points-at HEAD)@sha1:$(git rev-parse HEAD)"

[TheEdgeOfRage]

It seems that this is gonna be our only option. Thank you :)

[pragmaticivan]

Is there any chance this could be supported in Git, though? Having to push to an OCI repository represents cost, and it would be great if we could just use a prefix field for tags:

There's a case where a team could want to quickly test something in a pre-prod environment without merging a pull request, and having a tag prefix there would allow people to create temporary overrides of the pre-prod env while still being able to promote that change to a production env in compliance environments where the manual approval is still required (and needed for batching releases)