build_sysext: override FLATCAR_VERSION only for non-official builds

[tormath1]

In the current release, I noticed this error for all channels:

 INFO    build_sysext: This is a dev rebuild of an official release tag: No BUILD ID set in '/mnt/host/source/.repo/manifests/version.txt'.  Will use base squasfs BUILD ID for version check.
 INFO    build_sysext: Repo root FLATCAR_VERSION is '4081.0.0', squashfs build ID is '2024-09-03-2245'
 INFO    build_sysext: Setting FLATCAR_VERSION to '4081.0.0+2024-09-03-2245'
 WARNING build_sysext: Base squashfs version: 4081.0.0
 WARNING build_sysext: SDK board packages version: 4081.0.0+2024-09-03-2245
 ERROR   build_sysext: script called: build_sysext '--board=amd64-usr' '--image_builddir=/home/sdk/trunk/src/build/images/amd64-usr/alpha-4081.0.0-a1/prod-sysext-work/sysext-build' '--squashfs_base=/home/sdk/trunk/src/build/images/amd64-usr/alpha-4081.0.0-a1/prod-sysext-work/base-os.squashfs' '--generate_pkginfo' '--manglefs_script=/mnt/host/source/src/scripts/build_library/sysext_mangle_containerd-flatcar' 'containerd-flatcar' 'app-containers/containerd'
 ERROR   build_sysext: Backtrace:  (most recent call is last)
 ERROR   build_sysext:   file build_sysext, line 205, called: die 'Version mismatch between board flatcar release and SDK container flatcar release.'

I assume it's a side effect of this PR: #2259.

From my understanding, the "Base squashfs version" is equals to the actual released version for release builds (e.g 4081.0.0) - in this case, if we override the FLATCAR_VERSION with "4081.0.0+2024-09-03-2245" we are creating a version mismatch.

I added an extra-check to assert that we are building an official release, we do not override the FLATCAR_VERSION for official releases -> so we shoud not get a mismatch.

⚠️ NOT TESTED

EDIT: cc @t-lo if you can give a second look as you've worked in this area recently 🙏

[jepio]

Can this rely on ${COREOS_OFFICIAL} instead?

[tormath1]

I'm not sure - COREOS_OFFICIAL seems to be set conditionnaly from this result is_official "${vernum}" - which just checks if the vernum is like this: MAJOR.MINOR.PATCH - so it's OK but not in the case of a rebuild: a rebuild from a released version will have this semver structure but it's not an official build.

[jepio]

it's only set from the ci-automation, so a user rebuilding a release tag will not have it set unless they want to produce an "official" release. They would have to explicitly export it themselves.

[tormath1]

Yeah - I see some kind of similar logic here too:

scripts/common.sh

Lines 357 to 363 in 61b0004

	# Official builds must set COREOS_OFFICIAL=1 to use an official version.
	# Unofficial builds always appended the build identifier.
	if [[ ${COREOS_OFFICIAL:-0} -ne 1 && -n "${FLATCAR_BUILD_ID}" ]]; then
	FLATCAR_VERSION="${FLATCAR_VERSION_ID}+${FLATCAR_BUILD_ID}"
	else
	FLATCAR_VERSION="${FLATCAR_VERSION_ID}"
	fi

[tormath1]

cherry-picked to:

• flatcar-4081
• flatcar-4054
• flatcar-4012
• flatcar-3975

[github-actions]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/10703495878

[t-lo]

Great catch, thank you! This one's on me, I should have checked for COREOS_OFFICIAL / an empty build ID in the squashfs to begin with.
Thank you for the fix, looks good!