online devfile registry is providing invalid links

[benoitf]

Issue problem:
the hosted devfile registry should provide tagged version matching the hosted che deployed.

For example
https://che-devfile-registry.openshift.io/devfiles/quarkus/devfile.yaml

is linking quay.io/eclipse/che-quarkus:nightly which is something wrong but should link to a tag like 7.9.3, 7.10.0, etc.

Red Hat Che version:
che.openshift.io

[ibuziuk]

@benoitf interesting thingy that for plugins tags are correct, so the issue is related only for devfile registry

[ibuziuk]

There are 2 solutions I can propose for devfile-registry promotion on Hosted Che:

• when we promote release version to Hosted Che all the images including patched base images will be re-build and pushed to quay
• during the upstream release devfile registry will be automatically updated on Hosted Che prod-preview.

@nickboldt if the re-building is not an issue, I would rather opt for the first option, but the second one also works for me

[nickboldt]

patched base images will be re-build and pushed to quay
If you mean re-releasing all these https://github.com/eclipse/che-devfile-registry/blob/master/arbitrary-users-patch/build_images.sh ... then that's not done today since these images don't update every 3 weeks. cc: @ericwill

I'm not sure what you mean by " devfile registry will be automatically updated on Hosted Che prod-preview." ... does that mean the che-devfile-registry release would trigger some process on Hosted Che's prod-preview instance? Can that be triggered from a cico script, given that prod-preview is private and centos-ci is public? what process would need to be triggered?

Here's another idea...

• What if every release of che images (theia, machine-exec, devfile and plugin registries, etc.) when pushed to quay also updated a :latest or a :7.x tag, and you just used that tag in hosted che? (That's what we do for CRW images using a :2.1 or :2.2 tag for all the builds in that series.

Then you wouldn't have to do ANYTHING to pull the latest tag into hosted che... it would just be live as soon as the Che release was done.

• now, hosted che devfile reg points to 7.12.1
• Mykhailo kicks the Che 7.12.2 release
• 3 hrs later the devfile reg in hosted che would see :latest == 7.12.2

WDYT?

[ibuziuk]

and you just used that tag in hosted che?

@nickboldt we can not just update tags on staging - rollout update is powered by centos CI e.g. must be triggered via job

also, using "latest" for tags is not reliable approach, since the images could be updated

[ibuziuk]

job definition has been updated. Now release CI https://ci.centos.org/job/devtools-che-devfile-registry-release/ should also rollout update released version of the devfile registry

[ibuziuk]

Seem to work just fine e.g. 7.12.2 has been released yesterday and https://che-devfile-registry.prod-preview.openshift.io/devfiles/quarkus/devfile.yaml is now on stage with quay.io/eclipse/che-quarkus:7.12.2