|
| 1 | +# NooBaa Operator - CI & Tests |
| 2 | + |
| 3 | +1. [Introduction](#introduction) |
| 4 | +2. [Upgrade Tests](#upgrade-tests) |
| 5 | + |
| 6 | +## Introduction |
| 7 | + |
| 8 | +NooBaa employs a Continuous Integration (CI) process to ensure the reliability and quality of its software. |
| 9 | +NooBaa Tests cover various aspects of functionality and integration. |
| 10 | +This proactive approach to testing enables NooBaa to deliver stable and efficient solutions for its users. |
| 11 | + |
| 12 | +## Upgrade Tests |
| 13 | + |
| 14 | +The NooBaa operator upgrade tests are part of the continuous integration (CI) pipeline and are designed to verify the stability and reliability of the system during version transitions. |
| 15 | + |
| 16 | +The upgrade test process includes the following steps: |
| 17 | + |
| 18 | +1. **Initial Deployment**: The latest release of the NooBaa operator is deployed on a Kubernetes cluster by default, see - [NooBaa Latest Release](https://api.github.com/repos/noobaa/noobaa-operator/releases/latest). |
| 19 | +2. **System Initialization**: A fully functional NooBaa system is created, including resources such as buckets, objects, backing stores, and endpoints. |
| 20 | +3. **Upgrade Execution**: The operator is upgraded to the target version using the noobaa CLI, the default target version is the latest noobaa-operator nightly build that could be found in [quay.io/noobaa/noobaa-operator](https://quay.io/repository/noobaa/noobaa-operator?tab=tags). |
| 21 | +4. **Post-Upgrade Validation**: The health and functionality of the NooBaa system are verified after the upgrade. This includes checking the readiness of control plane components, data accessibility, and the integrity of configurations and runtime state. |
| 22 | + |
| 23 | +These tests simulate upgrade scenarios and are continuously executed in the CI pipeline to detect upgrade-related issues early and ensure smooth operator version transitions. |
| 24 | + |
| 25 | +### Run upgrade tests locally |
| 26 | + |
| 27 | +In order to run upgrade tests locally with the default source and target versions, run the following command - |
| 28 | +```bash |
| 29 | +make test-upgrade |
| 30 | +``` |
| 31 | + |
| 32 | +In order to run upgrade tests locally with custom source and target versions, run the following command - |
| 33 | +```bash |
| 34 | +UPGRADE_TEST_OPERATOR_SOURCE_VERSION=<upgrade-operator-source-version> UPGRADE_TEST_OPERATOR_TARGET_VERSION=<upgrade-operator-target-version> make test-upgrade |
| 35 | +``` |
| 36 | + |
| 37 | +For instance - |
| 38 | +```bash |
| 39 | +UPGRADE_TEST_OPERATOR_SOURCE_VERSION=5.17.0 UPGRADE_TEST_OPERATOR_TARGET_VERSION=5.18.6 make test-upgrade |
| 40 | +``` |
| 41 | + |
| 42 | +### Manual Upgrade Tests Action |
| 43 | + |
| 44 | +The following action is a dispatchable GitHub Action for running the upgrade tests manually. |
| 45 | +It was implemented as part of the continuous integration (CI) process to allow on-demand execution of upgrade scenarios outside the scheduled or automated test pipeline. |
| 46 | +See - [Manual Upgrade Tests Action](../../.github/workflows/manual-upgrade-tests.yaml). |
| 47 | + |
| 48 | +### Nightly Upgrade Tests Action |
| 49 | + |
| 50 | +A nightly Upgrade tests github actions runs every night at 4AM UTC. |
| 51 | +See - [Nightly Upgrade Tests Action](../../.github/workflows/nightly-upgrade-tests.yaml). |
0 commit comments