fix pure OCI deployment for rancher-roles-management units (!8351) · Merge requests · Sylva-projects / sylva-core

Closes #4274 (closed)

This MR fixes "pure OCI" deployment for rancher-roles-management units (and generally for Helm-based units that are defined only in management.values.yaml or workload-cluster.values.yaml):

tools/oci/push-helm-charts-artifacts.py builds no artifact for them
the use-oci-artifacts.values.yaml layer will now include units that are defined only in management.values.yaml or workload-cluster.values.yaml

Without this fix, those units cannot be deployed in an OCI-only deployment (not present in the use-oci-artifacts.values.yaml layer, so the GitRepository would be used, which will fail in an OCI-only deployment).

This MR has 4 commits (💡 hints for reviewers: read this one commit at a time):

one which is a light simplification/cleanup of recursive_dict_combine in yamlMerge.py, to allow calling it without it's last argument
one that modifies tools/oci/build-sylva-units-artifact.py to achieve the key purpose of this MR (using recursive_dict_combine in from yamlMerge.py to combine values.yaml, management.values.yaml and workload-cluster.values.yaml)
a last one which adds dummy units in values.yaml for the two units that are defined only in management.values.yaml or workload-cluster.values.yaml ; this is necessary, or else:
- tools/oci/push-helm-charts-artifacts.py would not build an artifact for them
  - for this, I also had to move a few field from management.values.yaml and workload-cluster.values.yaml in values.yaml
- when use-oci-artifacts.values.yaml is used in management context, it would include an incomplete definition for the rancher-cluster-role-bindings which is defined only in workload-cluster.values.yaml
- when use-oci-artifacts.values.yaml is used in workload context, it would include an incomplete definition for the rancher-role-management which is defined only in management.values.yaml

It's important to realize that the way the values.yaml layers are intricated with OCI artifact building tools is too complex; this will be fixable in the context of the refactoring of how we handle OCI for Helm, hopefully to land in %1.8.0

Testing

Tested by running ONLY_PRODUCE_USE_OCI_ARTIFACTS_VALUES=1 tools/oci/build-sylva-units-artifact.py before and after this MR.

Diff:

--- use-oci-artifacts-final.values.yaml.before  2026-06-24 11:09:14.124408914 +0200
+++ use-oci-artifacts-final.values.yaml.after   2026-06-24 11:09:23.837786501 +0200
@@ -325,10 +325,24 @@
     helm_repo_url: '{{ .Values.sylva_core_oci_registry }}'
   rancher-backup-restore-operator-crd:
     helm_repo_url: '{{ .Values.sylva_core_oci_registry }}'
+  rancher-cluster-role-bindings:
+    helm_repo_url: '{{ .Values.sylva_core_oci_registry }}'
+    helmrelease_spec:
+      chart:
+        spec:
+          version: 1.1.4
+    repo: null
   rancher-compliance:
     helm_repo_url: '{{ .Values.sylva_core_oci_registry }}'
   rancher-compliance-crd:
     helm_repo_url: '{{ .Values.sylva_core_oci_registry }}'
+  rancher-roles-management:
+    helm_repo_url: '{{ .Values.sylva_core_oci_registry }}'
+    helmrelease_spec:
+      chart:
+        spec:
+          version: 1.1.4
+    repo: null
   rancher-settings:
     helm_repo_url: '{{ .Values.sylva_core_oci_registry }}'
     helmrelease_spec:

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 Jun 24, 2026 by Thomas Morin

fix pure OCI deployment for rancher-roles-management units

Testing

CI configuration

Global config for deployment pipelines

Merge request reports