Provide gitlab pages to expose scheduled pipeline report (!7926) · Merge requests · Sylva-projects / sylva-core

What does this MR do and why?

Add a new feature in pipeline_schedule_report.py script, to produce a .json file that contain all the information we used to build the report. The file is produced when we pass: --json-file option or set JSON_REPORT_FILE variable
Two other options are added, they are only useful for the new report format (no effect on the MD), they allow to define a regex to match scenario and for theses scenario another regex to match job if theses jobs are failed / skipped the pipeline will be reported as setup failed. It's useful for upgrade case
Provide an .html pages that could be used to display the content of the json file in a nice way

This page can be hosted as a gitlab pages, the MR provide a job to deploy the pages in parallel environment (https://docs.gitlab.com/user/project/pages/parallel_deployments/) allowing to have multiple gitlab pages deployment in parallel (for each of our release branches, for that we'll have to configure each jobs with a CUSTOM_PAGES_PREFIX variable)

It's also possible to trigger the publication of the pages in MR (manual jobs) in this case it will use another env

eg: https://sylva-projects.gitlab.io/sylva-core/mr-7926/

This page offer multiple features impossible to have on the wiki report.

It allow to filter deployments:

Using plain text search
Using tags based on OS, infra, providers etc..
Status

It keep the direct link to create an issue or a investigation report on the wiki. For the report if the page already exist it will also be displayed

Each deployment is clickable to access to the history with the details of the failed jobs etc..

A new menu is available "Failure analysis" it display the whole list of failed jobs, with their failure rate, link to the deployment where we detect them.

The html part was generated with the use of Co-pilot tooling

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	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 May 22, 2026 by Loic Nicolle

Provide gitlab pages to expose scheduled pipeline report

What does this MR do and why?

Related reference(s)

Test coverage

CI configuration

Global config for deployment pipelines

Merge request reports