introduce _internal.sylva_branch (!9114) · Merge requests · Sylva-projects / sylva-core

Closes #4527 (closed) <-- read this first

This MR:

introduces _internal.sylva_branch:

sylva_branch holds either main, for code not yet released (e.g. MR targeting main), or release-<x> for code which is living in a release-<x> branch or an MR targeting release-<x> So in sylva-core 'main' Git branch, sylva_branch is main, and with 1.7 as an example, in sylva-core release-1.7' Git branch, sylva_branch is release-1.7`
injects this information in sylva-units-status ConfigMap
- the pytest framework will be able to leverage this to condition which tests to run based on the Sylva version, in a way that can work cleanly including on dev branches
uses it in CI framework to be able to tell which CI deployment values to use
- the code we have today that leverages branch names, and MR target branch name when available, it still kept:
  - to handle the interim situation where this MR won't have been backported to all release-1.x branches yet
  - for backwards compatibility with downstream CIs that reuse this same functionality
- this evolution is done in such a way that downstream CIs that reuse this same functionality, can leverage it even if they use a different branch naming scheme
- one change that was required to achieve this: we need to move the place where SYLVA_CI_VERSIONED_CI_VALUES_FOLDER is computed, because it now needs to be done after checking out the version we're going to use, ie. after .update_revision
  - a side-effect of that is that we can't display SYLVA_CI_VERSIONED_CI_VALUES_FOLDER as part of the deployment information information block at the start of the job -- I think this is a reasonable thing to lose
  - to compensate for that, the SYLVA_CI_VERSIONED_CI_VALUES_FOLDER is now displayed later in the console, at the place where it is used

Tests

To test this MR, I did the following:

backported this MR (!9121 (merged)) -- of course in this backport, we have sylva_branch: release-1.7
on this MR here, I added a scenario to try to upgrade from the dev branch of that backport
in this pipeline we can observe that SYLVA_CI_VERSIONED_CI_VALUES_FOLDER is set to 1.7 (in deploy mgmt cluster job), as desired

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	Deployment option list and description
🎬	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
🔴	Disabled 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 Available platform list and description
⚡	Pipeline control	`autorun`, `manual` or `blocking`. Can be used to override global config and start a deployment pipeline the required way

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 Sep 11, 2026 by Thomas Morin

introduce _internal.sylva_branch

Tests

CI configuration

Global config for deployment pipelines

Merge request reports