What does this MR do and why?

This MR is a refactoring of pipeline_schedule_report.py script.

The main purpose is to provide a more readable scheduled pipeline report. As I found the legacy script hard to maintain, I rewrote most of it. For the review, I think it's better to just look at the script content.

Compared to the previous script, this MR brings:

cleaner log
requirement.txt to install mandatory python packages
--help menu and all options can be configured via CLI and/or via environment variable (useful in gitlab-ci context)
drops legacy code to handle older version of CI (which is not used anymore), drops legacy code to drop OCI option as we don't use it anymore since a while too

The report itself is organized differently.

A header, with the date, the number of pipelines in the history and a brief legend
Each scheduled pipeline is defined under a major section
In this section we'll find all related deployment pipelines
For each of them, we can find a table that summarizes the latest run

Key information:

date
did the status change since the previous run (➖ No change, ⬆️ Improved, ⬇️ Regressed)
Direct link to each deployment/upgrade job
Number of success/total tests and a detailed report that displays only the faulty tests (with a direct link to the job)

Then we have:

Success: 2/10 (20.0%) Partial: 7/10 (70.0%) Failure: 1/10 (10%) 🟢 1 days ago 🟡 0 days ago 🔴 None

This displays the success rate for:

total success, partial success (when deploy/upgrade succeed but some tests failed), failure ratio (when deploy/upgrade failed)

🟢 Last time since all jobs succeeded.

🟡 Last time since partial Success: When some tests failed but the deployment/upgrade jobs succeeded.

🔴 Last time since total failure: When any deploy/upgrade jobs failed.

After that we have a collapsed section Show history that contains the history of previous runs.

Report example: tmp_report_loic

I also change a bit the way we upload the report, now it will upload the complete report as it did previously but we also publish the dated copy with the same content instead of running 2 times the script and provide only partial output in dated copy

Related reference(s)

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

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 Oct 29, 2025 by Loic Nicolle

Refactor pipeline_schedule_report.py script

What does this MR do and why?

Related reference(s)

Test coverage

CI configuration

Global config for deployment pipelines

Merge request reports