discussion: multiple subs to the same repo

[krancour]

@hiddeco has been working on #1583 and posed the question of what qualifies as a "duplicate" repo subscription. i.e. Could it be valid for one Warehouse to have n > 1 subs to the same repo, with different constraints on each sub, such that n (potentially) different versions of the artifact in question are selected to be included in the Freight produced by the Warehouse?

To be clear, no one has asked for this and there's probably room for debate around the practicality of ever having one Warehouse subscribe n > 1 times to the same repo. This is, however, something that we should probably settle before diving into pluggable promotion mechanisms as it may impact the design.

We decided that for now we limit Warehouses to just one subscription per repository.

The rest of this issue captures why we chose that path for now and what we think would be required if it were determined in the future that this constraint should be lifted.

The Problem

In short, repo URLs are currently used as the sole identifier that links an artifact in a piece of Freight to a thing that a promotion mechanism is expected to update.

Examples:

• A promotion mechanism that updates a git repository matches the repository it updates to an artifact in the Freight by URL.

• A promotion mechanism that updates an Argo CD Application matches the specific ApplicationSource it updates to an artifact in the Freight by URL.

The Proposed Solution (if ever required)

Allow subscriptions to have an optional, user-assigned, unique-per-URL (enforced by webhook), id/label/discriminator. (What we actually call it is a bridge we can cross later.)

Promotion mechanisms can optionally use such a field to match artifacts from a specific subscription when any disambiguation is necessary.

It won't matter that the underlying thing updated by a promotion mechanism won't be aware of the discriminator. For example, an Argo CD Application having one of its ApplicationSources updated would have no field that the discriminator is matched to. Rather, it would be Kargo itself using such a discriminator to disambiguate which artifact(s) a promotion mechanism is handed to act upon.

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.

[krancour]

Keeping this open only because I think it plays into #1680 a bit.

[krancour]

I don't believe this is relevant at present.

Presently, Warehouses cannot subscribe twice to the same repository, but Stages can request Freight originating from multiple Warehouses, and therein lies the possibility to obtain multiple versions of an artifact from the same repository. Moreover, the mechanism for disambiguating which of those artifacts a given promotion mechanism is meant to operate on is similar to what was discussed here.

I think this issue is adequately addressed for the time being.