Consider referencing the images by digest instead of by tag. On the one hand, this really ensures immutable image references during packaging. On the other hand, using digest format is better for ImageContentSourcePolicy in disconnected environments.
@harshad16 @VaishnaviHire @Jooho relevant for list of images to include in operator bundle packaging, too. It is best practice to use digest format throughout.
You can instead add the full tag including RELEASE under tags instead of image_name. Basically just a different place to use for the tag. image_name is used in pulling images. @harshad16 tags are shown in Elyra GUI, just like display_name.
Also, since sha256 unique digests are used now, add pull_policy with value ifNotPresent (which in pipeline runtime containers translates to imagePullPolicy).
When used to dynamically add json files containing the runtime images, skopeo could be used as well, depending on user input. Question is if the list of usable runtime images should even be static, is there i.e. a Github actions workflow that keeps runtime images list in sync with Jupyter GUI IDE images? For contrib, I could even imagine assembling that list of jsons on the fly with image builder command line utility, see linked issue.
https://github.com/opendatahub-io-contrib/workbench-images/tree/main/snippets/ides/1-jupyter/files/runtime-images
Consider referencing the images by digest instead of by tag. On the one hand, this really ensures immutable image references during packaging. On the other hand, using digest format is better for ImageContentSourcePolicy in disconnected environments.
@harshad16 @VaishnaviHire @Jooho relevant for list of images to include in operator bundle packaging, too. It is best practice to use digest format throughout.
You can instead add the full tag including RELEASE under tags instead of image_name. Basically just a different place to use for the tag. image_name is used in pulling images. @harshad16 tags are shown in Elyra GUI, just like display_name.
Also, since sha256 unique digests are used now, add pull_policy with value ifNotPresent (which in pipeline runtime containers translates to imagePullPolicy).
i.e.
See
https://github.com/typhoonzero/elyra/commit/f369c964b2b0b46bfeb19ec629e9d9b030ffaa08#diff-1a8d23b67da009a738fc0755eac24d28363fd900a989eaa32d58058c9c8771e5
Regarding automation: skopeo inspect can get an image's digest it seems.
When used to dynamically add json files containing the runtime images, skopeo could be used as well, depending on user input. Question is if the list of usable runtime images should even be static, is there i.e. a Github actions workflow that keeps runtime images list in sync with Jupyter GUI IDE images? For contrib, I could even imagine assembling that list of jsons on the fly with image builder command line utility, see linked issue.
The release search and replace can stay as it is at https://github.com/opendatahub-io-contrib/workbench-images/blob/main/snippets/ides/1-jupyter/jupyter.snippet#L62