use diskimage-builder 0.7.7 == 0.7.4 (!6439) · Merge requests · Sylva-projects / sylva-core

Context

We'll have to take care about tagging branching for release-1.6 very soon (the plan is do do this tomorrow).

The process will be similar as what we did for 1.5:

in sylva-core: branch release-1.5 from current main HEAD
in each sylva-elements repo that sylva-core consumes:
- example for sylva-elements/xxx/foobar
- assuming sylva-core currently uses foobar version x.y.z
- we'll fork release-x.y in foobar repo -> this is what sylva-core release-1.6 branch will track, and where we'll do any backport we need
- we'll also create an x.(y+1).0 tag -> this is the new release that sylva-core main will use soon after
there is one corner case we need to cover: the case where sylva-core uses foobar x.y.z, but there is a x.y.(z+1) in foobar that sylva-core does not consume yet - you can read more about this here: Creating a New Release Branch for Sylva core

Problem

diskimage-builder is in this "corner case" mentioned above: sylva-core currently uses 0.7.4, and the 0.7.6 we have done isn't yet consumed by sylva-core and we won't try to use it before cutting 1.6.0

we'll have to cover this in a particular way because this diskimage-builder repo is particular: each time we do a new tag (even on the same commit) we may build a different OS image (the set of distro packages can have changed in the meantime, we have no way to pin them)

Here is the plan:

do a 0.7.7 on same commit as 0.7.4 (✔️ already done)
use it in sylva-core before the actual fork of sylva-core release-1.6, to validate these new OS images --> this MR

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	`capd`, `capo`, `capm3`
🚀	Bootstrap Provider	`kubeadm` (alias `kadm`), `rke2`, `okd`, `ck8s`
🐧	Node OS	`ubuntu`, `suse`, `na`, `leapmicro`
🛠️	Deployment Options	`light-deploy`, `dev-sources`, `ha`, `misc`, `maxsurge-0`, `logging`, `no-logging`, `cilium`
🎬	Pipeline Scenarios	Available scenario list and description
🟢	Enabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🏗️	Target platform	Can be used to select specific deployment environment (i.e `real-bmh` for capm3 )

Global config for deployment pipelines

autorun pipelines
allow failure on pipelines
record sylvactl events

Notes:

Enabling autorun will make deployment pipelines to be run automatically without human interaction
Disabling allow failure will make deployment pipelines mandatory for pipeline success.
if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Edited Dec 17, 2025 by Thomas Morin

use diskimage-builder 0.7.7 == 0.7.4

Context

Problem

CI configuration

Global config for deployment pipelines

Merge request reports