Aliasing subscriptions in warehouse

[etutuit]

Checklist

• I've searched the issue queue to verify this is not a duplicate feature request.
• I've pasted the output of kargo version, if applicable.
• I've pasted logs, if applicable.

Proposed Feature

Aliasing subscriptions in warehouse, so the same registry, with different configurations, could be added more than once to the warehouse.

Motivation

Currently it is possible to add more than one subscription with the same registry. It is bugged though, so if this feature request will be rejected, it should be considered a bug report as such config should be then rejected as not valid.

After creating warehouse with such configuration of subscriptions:

spec:
  subscriptions:
    - image:
        ignoreTagsRegexes:
          - ^release-.*$
        discoveryLimit: 20
        imageSelectionStrategy: NewestBuild
        repoURL: redacted.com/example/template-go
        strictSemvers: true
    - image:
        allowTagsRegexes:
          - ^release-.*$
        discoveryLimit: 20
        imageSelectionStrategy: NewestBuild
        repoURL: redacted.com/example/template-go
        strictSemvers: true

The warehouse is stuck in Waiting for discovery to complete and does not show second subscription in diagram.

Although the subscriptions are visible in subscriptions and freight creation tabs. The subscriptions have exactly same name as it is based on the registry address.

Aliasing subscriptions would allow proper presentation and differentiating them in diagram and in warehouse subscriptions and freight assembly tabs.

Currently this setup basically works as it is possible to create freight from it by choosing desired subscription and image tag in it. For me it makes it easy to choose either latest image with only a hash to drop on dev environment, or choose subscriptions where are images with proper release tags to deploy somewhere else.

Nevertheless user experience is extremely poor due to presented weird behaviours. I assume that's not intended usage and currently to make it work without issues another warehouse should be created to accommodate such setup, but I don't see anything against making it work as creating another warehouse to have different filtering on registry shouldn't be necessary.

Sidenotes

I don't know if someone uses registries like that, but if anyone would like to have different images in the same registry differentiated only by tag and create freights with them, then aliasing could be able to make that happen, but then another flag should be created so it would be clear if freight should expose more images from one registry.

There is also such error popping out which I assume is from freight auto creation what would suggest that it processes subscriptions a bit differently than manual creation which works properly.

Error creating Freight "1924989936af82849f6ae273463a007d163aef6d" in namespace "example-kargo": admission webhook
freight.kargoakuity.io" denied the request: Freight.kargo.akuity.io 8f746067ad94aa9bc052e25cad9affe63f207b33" is invalid: images: Invalid x value: null: multiple artifacts found for subscription "redacted.com/example/template-go" of Warehouse "test"

[krancour]

My recollection is that we had validation to prevent multiple subscriptions to the same repo within one warehouse. I can look into whether that isn't working for some reason.

That aside, the alias thing is a neat idea for how we could potentially approach this. (If the answer turns out not to simply be fixing the validation to shut down the possibility of two subs to the same repo, that is.) It potentially touches a lot of things, so it's something I don't think we'd undertake lightly.

The idea does solve an edge case that I was anticipating should we ever pursue the ideas of "junctions" as a new kind of Freight origin, as mentioned in various issues. "Junctions" would hypothetically repackage Freight from multiple origins into a new Freight resource. This would allow taking artifacts that traversed the pipeline independently up to a point and combining them to advance further as a unit. One edge case that could have been problematic would be combining two Freight resources where both reference artifacts from the same repository. The aliases idea would allow for some differentiation.

So this is a neat idea that deserves a closer look when time permits, but I will in the meantime check if there's some broken validation here.

[jidr]

The "Junction" idea sounds amazing. We're approaching the point where we are contemplating implementing something similar for our monorepo deployment manifest strategy, where we use a similar strategy as above but with includePath as a filter. We currently have a warehouse per microservice and create freight based on the microservice's rendered manifests. Either a junction that joins multiple freights in to one or aliasing of unique configurations of the same subscriptions would solve our problem I believe.

[krancour]

I'm closing this as a duplicate of #2839, but will make a point of referencing this issue over there so additional context found herein is not lost.