[devfile registry]: decouple oci image lifecycle

[benoitf]

Is your task related to a problem? Please describe.

Today, every night we rebuild devfile parent images and also on every releases
but sometimes the parent images are changing and some tags are rolling tags so we can't rely on digests of the images as digests are no longer published.

Describe the solution you'd like

Decouple the building of the images and their usage.
We could track every change in parent images but it does not prevent to have new changes or 'couple of hours before the release changes'.
We really want to own when to switch to a new image and not be forced to do so.

here the approach, similar to the plug-in registry that we could take.
We build like every night images and we publish new tags of these images if something has been changed.
for example, we build quarkus image and we publish it with the tag based on the digest of the image being built.

example:
build daily quay.io/eclipse/che-quarkus
the resulting digest is d476a91ab415 so we publish it under both quay.io/eclipse/che-quarkus:nightly and quay.io/eclipse/che-quarkus:d476a91ab415

in the devfiles, we reference quay.io/eclipse/che-quarkus:d476a91ab415 instead of quay.io/eclipse/che-quarkus:nightly

When releasing a new version of the devfile registry.
Either we do almost nothing on these images (we keep the existing digest links) or we copy the tags to the version tag
for example we copy quay.io/eclipse/che-quarkus:d476a91ab415 to quay.io/eclipse/che-quarkus:7.30.0 and update devfile to use the tag and not the digest.

Separate to that, we can have scripts that monitor if new images are available and provide pull requests to use new version of the images in the devfiles (and if tests are ok we can safely merge it)

Describe alternatives you've considered

N/A

Additional context

global idea is to prevent to introduce unwanted changes in our images and own the time when to upgrade to new version of images

[nickboldt]

Impacts to build process:

• ./update_devfile_patched_image_tags.sh in Dockerfile will no longer be needed, as the values in there won't be "nightly" but "specific tags"
• when devfiles move to be colocated with che-samples projects instead of being in the che-devfile-registry, this process will have to change again

[nickboldt]

Blocked by #19341 - need to move to new devfile format, devfile registry, BEFORE churning the release process now and again in a few weeks.

[nickboldt]

Found sample code for being able to authenticate w/ reg.rh.io registries. Might be worth enabling that for pulling digests.

https://gist.github.com/nickboldt/a884449ada7a6cdcda85e58c984b5eea

Fix for registry auth: eclipse-che/che-devfile-registry#407 merged.

eclipse-che/che-devfile-registry#406 (comment) has comments showing the re-run worked (and found the digests as expected).

FYI @mkuznyetsov ^

[benoitf]

so to clarify a little bit,

We commit Dockerfiles in their specific directories
there will be a Dockerfile in a che-quarkus directory that will produce a che-quarkus image

The digest of the parent is in that Dockerfile (so we don't need base_images file anymore)

if we need some helper for script to find updates we can do like for redhat catalog with a prefix of the image to track

# quay.io/quarkus/centos-quarkus-maven:21.0-java11
FROM quay.io/quarkus/centos-quarkus-maven@sha256:c472acf9e8ef7f722469a8dc37a7a2dfed220cfb22b9fe36a051fe80c153448f

when a directory of a Dockerfile is updated we rebuild and publish that image

And when a new image is available on quay.io we check if we need to bump devfiles in the registry to new digests.

[vitaliy-guliy]

A draft PR eclipse-che/che-devfile-registry#464 with

• decoupled dockerfiles for each image instead of keeping them in one file
• build script to build all or specific image.

It needs to be reworked as well:

• script / gh-action, which tracks changes in upstream repo of base images, updates Dockerfiles by applying new digest and creates a pull request to be able to merge it manually.
• script / gh-action, that tracks changes of Dockerfiles, entrypoint.sh, etc.., rebuilds base images and pushes them giving new tag (use commit ID for that). This action will also update devfiles by applying new tags of images with following creating of pull request (to merge it manually).
• gh-action to check pull requests

[nickboldt]

Related work: #20610

We have both the OLD golang 1.14 sidecar and the NEW golang 1.16.6 sidecar in the che-operator CSV. Do we need both? Why are we rebuilding/retagging the old 1.14 sidecar every week in http://quay.io/eclipse/che-golang-1.14:7.37.1 when we have the newer one in http://quay.io/eclipse/che-plugin-sidecar:go-ae6cfa4 ?

[vitaliy-guliy]

Why are we rebuilding/retagging the old 1.14 sidecar every week in http://quay.io/eclipse/che-golang-1.14:7.37.1 when we have the newer one in http://quay.io/eclipse/che-plugin-sidecar:go-ae6cfa4 ?

My latest PR eclipse-che/che-devfile-registry#483 fixing it.