Add a new CI scenarios with more explicit names

What does this MR do and why?

This MR, refactor a bit the scenario definition to avoid code duplication (mainly around timeout)

It also introduce new scenario

• no-wkld , to only deploy mgmt cluster without any update & no workload cluster
• rolling-update-no-wkld, test rolling update of the management cluster (no workload)
• sylva-upgrade-no-wkld , test sylva upgrade of the management cluster (no workload)
• simple-update-no-wkld , test simple update of the management cluster (no workload)

rename k8s-upgrade to wkld-k8s-upgrade as it only affect workload cluster

close #1735 (closed)

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
🐧	Node OS	ubuntu, suse
🛠️	Deployment Options	light-deploy, oci, ha, misc
🎬	Pipeline Scenarios	no-wkld simple-update simple-update-no-wkld rolling-update rolling-update-no-wkld wkld-k8s-upgrade nightly sylva-upgrade sylva-upgrade-no-wkld sylva-upgrade-from-x.x.x preview

• 🎬 preview ☁️ capd 🚀 kadm 🐧 ubuntu 🛠️ oci

• 🎬 preview ☁️ capo 🚀 rke2 🐧 suse

• 🎬 preview ☁️ capm3 🚀 rke2 🐧 ubuntu

• ☁️ capd 🚀 kadm 🛠️ light-deploy 🐧 ubuntu

• ☁️ capd 🚀 rke2 🛠️ oci,light-deploy 🐧 suse

• ☁️ capo 🚀 rke2 🛠️ oci 🐧 suse

• ☁️ capo 🚀 kadm 🛠️ oci 🐧 ubuntu

• ☁️ capo 🚀 rke2 🎬 no-wkld 🛠️ ha 🐧 ubuntu

• ☁️ capo 🚀 kadm 🎬 wkld-k8s-upgrade 🐧 ubuntu

• ☁️ capo 🚀 rke2 🎬 rolling-update-no-wkld 🛠️ ha,misc 🐧 suse

• ☁️ capo 🚀 rke2 🎬 sylva-upgrade-from-1.3.x 🛠️ ha,misc 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🐧 suse

• ☁️ capm3 🚀 kadm 🛠️ oci 🐧 ubuntu

• ☁️ capm3 🚀 kadm 🎬 rolling-update-no-wkld 🛠️ ha,misc 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🎬 wkld-k8s-upgrade 🛠️ ha 🐧 suse

• ☁️ capm3 🚀 kadm 🎬 simple-update-no-wkld 🛠️ ha 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🎬 sylva-upgrade-no-wkld 🛠️ misc,ha 🐧 suse

• ☁️ capm3 🚀 kadm 🎬 rolling-update 🛠️ ha 🐧 suse

Global config for deployment pipelines

• autorun pipelines
• allow failure on pipelines

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.