See thread:

https://redhat-internal.slack.com/archives/C08A1KD7TNY/p1751464147162859

Tomas said:

By default, new image is downloaded only if tag changed (unless it is latest in that case it is always downloaded). This is the same logic Kubernetes uses.

So we either want to have a process whereby

• files like https://github.com/redhat-developer/rhdh/blob/main/catalog-entities/marketplace/plugins/github-catalog-integration.yaml#L71 are updated to refer to the latest specific x.y.z tag, every time a new plugin is pushed to quay (dev preview) or RHEC (TP/GA), eg and update to https://quay.io/repository/rhdh-plugin-catalog/backstage-plugin-catalog-backend-module-github?tab=tags

• or we have to have floating tags that behave like an operator subscription fast-1.7 channel and update the marketplace so that additional floating tags like fast-1.7 or latest-1.7 are also treated as "pullalways" tags; side effect: adds startup time and adds load to image registries, which could also break things unexpectedly for airgap customers.

Of course the reason why floating tags are NOT used in our helm chart or operator bundle CSV is because they float (and cause unexpected updates / breakages with airgap users) ... and so a better solution would be unchanging tags or even pinned image digests.

Therefore to have a way to update the https://github.com/redhat-developer/rhdh/blob/main/catalog-entities/marketplace/ with pinned digests every time a new compatible plugin is released, we could do one of these things:

1. the catalog-entities needs to be consumed directly from github (or a source tarball for airgapped solutions) from the correct branch; or

2. the catalog-entities needs to be published SEPARATELY as its own oci artifact/container and consumed & deployed by the RHDH chart/operator; or

3. every time we do a plugin update, we need to regenerate a new RHDH container and publish that with a new operator-bundle (2 containers)

I don't love any of those solutions:

1. relies on 3rd party hosting service; least process-heavy solution however (and we could include the sourcesinside the RHDH container at the time of the .0 or .z release, as a fall back for airgapped)

2. needs yet anothere Konflux pipeline and OCI artifact, plus updates to the chart/operator flows; adds complexity without much gain

3. uses existing Konflux processes but sorta defeats the purpose of getting rid of wrappers as we have to do an rhdh-hub-rhel9 and rhdh-operator-bundle container release for EVERY .z plugin update

---------------

After discussion today, the plan is to move ahead with

2. the catalog-entities needs to be published SEPARATELY as its own oci artifact/container and consumed & deployed by the RHDH chart/operator

this means we need a new OCI artifact, plus updates to the chart and operator bundle to include the new artifact in the deployment. Might need to convert this to a Feature.