[Rework CI] part2 - Use meaningful deployment job names with emoji 😋 (!2906) · Merge requests · Sylva-projects / sylva-core

What does this MR do and why?

This MR is the second step of CI rework about deployment tests.

This MR introduces deployment names which includes their own configuration. For example:

As you can see, deployment names are built with up to 5 parts:

☁xxxx indicates infra provider (capd, capo or capm3-virt)
🚀xxxx indicates bootstrap provider (kubeadm or rke2)
🎸xxxx indicates node OS (ubuntu ort suse)
(optional) 🛠xxxx indicates deployment options -> must correspond to a CI value file
(optional) 🎬xxxx indicates deployment scenario (rolling-update, mgmt-rolling-update, k8s-upgrade or migration)

Scenario are triggered similarly as currently using labels:

label ci-featuretest-rolling-update produces deployments with 🎬rolling-update
label ci-featuremgmt-rolling-update produces deployments with 🎬mgmt-rolling-update
label ci-featuretest-upgrade-from-1.1.1 produces deployments with 🎬migration
🎬k8s-upgrade is triggered with nightly schedule pipelines

Options are parsed in deployment script to dynamically apply requested CI values. This implies some CI values alignment as done in sylva-projects/sylva-elements/ci-tooling/ci-deployment-values!85 (merged)

This MR has been tested with various configurations

Standard deployment pipelines have been tested here

Notes:

🎬k8s-upgrade has not been actually tested. Maybe we could had a specific ci-feature label for this ?
Sylva version upgrade scenario is called here migration. It may be subject to debate.
As @loic.nicolle noticed, this imply a change in default schedule pipelines which currently run mgmt-rolling upgrade + wkld cluster k8s upgrade. A rework of schedules may be required.

Edited Oct 03, 2024 by Médéric de Verdilhac