Skip to content

Resolve "Automate per-release upgrade testing"

Varac requested to merge 961-automate-per-release-upgrade-testing into main

Closes #961 (closed)

Most notable changes:

  • We now have a "default" pipeline and a "upgrade_test" pipeline. The Upgrade test pipeline first runs the default pipeline to set up an older version (v0.8) of Stackspin, then runs an upgrade and runs all the tests again. The different pipelines are defined in a folder called .gitlab/ci_pipelines.
  • install_stackspin and app_tests are "child pipelines". The install_stackspin child pipeline installs Stackspin and runs the tests for core components. After it is finished, the app pipelines run tests for all other components, as well as taiko or cert tests for core components if necessary.
  • The .gitlab/ci_templates folder contains a bunch of files with reusable templates that are used in the different parent pipelines as well as some child pipelines
  • I have changed some files in test/ because some tests were triggered with different "RESOURCE" names. I unified this to be able to unify all app tests in the app child pipeline.
  • The test_resources.py pytest now also checks if a resource is the right revision. This is necessary because after performing an upgrade you want to be sure a kustomization was upgraded, and isn't still reporting a "ready" state from the installation step.
  • the .gitlab-ci.yml file in the project root is just a shell that imports the files from .gitlab/ci_pipelines based on what pipeline needs to run.
Edited by Maarten de Waard

Merge request reports