[backport-1.6]: doc: have units-description.md include appVersion for Helm charts (!6665) · Merge requests · Sylva-projects / sylva-core

What does this MR do and why?

Updating generate_units_documentation.py script to retrieve appVersion from Helm charts. AppVersion field is populated inside units-description.md for each component based on Helm Charts.

The script depends on the Python oras module and is used in the check_versions_downgrade CI job. I evaluated installing oras in the Docker image, but this is blocked by PEP 668, which prevents installing Python packages system-wide via pip :

error: externally-managed-environment

× This environment is externally managed
╰─> 
    The system-wide python installation should be maintained using the system
    package manager (apk) only.
    
    If the package in question is not packaged already (and hence installable via
    "apk add py3-somepackage"), please consider installing it inside a virtual
    environment, e.g.:
    
    python3 -m venv /path/to/venv
    . /path/to/venv/bin/activate
    pip install mypackage
    
    To exit the virtual environment, run:
    
    deactivate
    
    The virtual environment is not deleted, and can be re-entered by re-sourcing
    the activate file.
    
    To automatically manage virtual environments, consider using pipx (from the
    pipx package).

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

Using --break-system-packages in the Dockerfile I think is not a good option.

For consistency with existing CI logic, I initially used:

pip3 install oras --break-system-packages

This is already done in https://gitlab.com/sylva-projects/sylva-core/-/blob/main/.gitlab/ci/main-pipeline-checks.yml?ref_type=heads#L305 .

Installing oras inside a Python virtual environment is possible to avoid using "--break-system-packages", but it would introduce a different approach for the same dependency in the same CI file.

After this approve I have to replicate this fix that I missed also on the main branch.

Test coverage

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.

Closes #3413 (closed)

Edited Jan 23, 2026 by Alex Ghita

[backport-1.6]: doc: have units-description.md include appVersion for Helm charts

What does this MR do and why?

Related reference(s)

Test coverage

CI configuration

Global config for deployment pipelines

Merge request reports