Read UBI_TAG from CNG at the release tag

release-helper.sh now reads UBI_TAG from UBI_MICRO_IMAGE in CNG's ci_files/variables.yml at the release tag. A UBI_TAG set in the environment still wins. A release run then follows CNG, so a hand-typed default can no longer revert it.

This is @WarheadsSE's suggestion on !83 (merged), built.

Why the two values drifted

How UBI_TAG resolves

flowchart TD
  A[Release tag checked out] --> B{UBI_TAG set in the environment?}
  B -- yes --> E[Use it]
  B -- no --> C{Tag like 9.8 in CNG variables.yml?}
  C -- yes --> D[Use its tag, such as 9.8]
  C -- no --> F[Stop with an error]
  E --> G[BASE_IMAGES built from UBI_TAG]
  D --> G

The lookup runs after the checkout and before base-images.sh is sourced, because sourcing builds BASE_IMAGES from UBI_TAG (release-helper.sh:17-24, base-images.sh:8-39). It matches the lookup at release-helper.sh:39-45. A missing key, or a value not like 9.8, stops the run with a message. The minimal image follows the same UBI_TAG (base-images.sh:12).

load-ubi-images.sh and build-script.sh source base-images.sh without a release lookup, so they still read its default. That is local build tooling, and I left it as it is.

Checks

Against v19.5.1-ubi and Repo1 development:

  • master, UBI_TAG unset: 16 of 16 projects change, only 9.7 to 9.8.
  • This branch, UBI_TAG unset: logs UBI_TAG=9.8 from CNG, with the same changes byte for byte.
  • This branch, UBI_TAG=9.7: no project changes.
  • v19.0.0-ubi, UBI_TAG unset: reads 9.7, not the 9.8 default.
  • UBI_MICRO_IMAGE removed from a local copy of a tag, or given a # pinned comment: exit 1 with the message. The removed copy runs normally with UBI_TAG=9.7.
  • Every -ubi tag since v17.3.0 (277) carries one UBI_MICRO_IMAGE line with a tag like 9.8.
  • shellcheck as CI runs it: 21 scripts, no findings.

An AI coding assistant helped draft this change and its description.

Merge request reports

Loading
Loading