[RFE] Auto-detect latest release versions in release builds

[t-lo]

Current situation

While new Kubernetes patch-level releases of all supported minor versions are auto-detected and the latest one is built, a similar feature is not implemented for docker, docker-compose, and wasmtime.

Impact

New versions need to be specified manually in order to be included in a release build.

Ideal future situation

New versions are automatically detected by release builds.
Ideally, the implementation is modular and makes it easy to add new components / sysexts to the release auto-build.

Follow-up tasks

• build new releases on a schedule (e.g. daily, weekly, etc) to keep "latest" release up to date with upstream releases.
• automatically tag "latest" in the build instead of relying on manual tagging. Done. Release CI action will re-tag.

[jsalatiel]

Could the same be added to cri-o ?

[tormath1]

Most of the components are pulled from Github releases (except Tailscale, Docker and Keepalived). To get the latest we can inspire from how we fetch the CNI components for Kubernetes sysext:

sysext-bakery/create_kubernetes_sysext.sh

Lines 92 to 98 in 2112078

	# install CNI.
	version="${CNI_VERSION}"
	if [[ "${CNI_VERSION}" == "latest" ]]; then
	version=$(curl -fsSL https://api.github.com/repos/containernetworking/plugins/releases/latest | jq -r .tag_name)
	echo "Using latest version: ${version} for CNI plugins"
	fi
	curl -o cni.tgz -fsSL "https://github.com/containernetworking/plugins/releases/download/${version}/cni-plugins-linux-${ARCH}-${version}.tgz"

In this file we will set crio-latest for example:

sysext-bakery/release_build_versions.txt

Line 26 in 2112078

crio-1.28.4

and we can still track specific versions.

For non github releases, it has to be handled with a custom way for each.

[mnbro]

Can we implement this also for k3s?

[tormath1]

Can we implement this also for k3s?

@mnbro thanks for the suggestion. This is done here #98 with rke2 as well.

[mnbro]

Can we implement this also for k3s?

@mnbro thanks for the suggestion. This is done here #98 with rke2 as well.

@tormath1 thank you!

Maybe this is not the right place but do you think that also adding k0s and also supporting its major/minor releases would be possible? In this way, Flatcar Linux OS would have a plug-and-play support for all major k8s distributions.

[tormath1]

@mnbro usually Kubernetes distribution (k3s, rancher, etc.) are installed via systemd-sysext. Having a k0s sysext would be totally great and possible.
Two options:

• open an issue on this repository to ask for this sysext
• implement yourself the recipe to build the sysext and add some documentation (you can take inspiration of existing contributions: e.g k3s)

[mnbro]

@mnbro usually Kubernetes distribution (k3s, rancher, etc.) are installed via systemd-sysext. Having a k0s sysext would be totally great and possible. Two options:

• open an issue on this repository to ask for this sysext
• implement yourself the recipe to build the sysext and add some documentation (you can take inspiration of existing contributions: e.g k3s)

@tormath1 PR #99 should implement k0s sysext.