Andrey Kolkov
8ea589230f
## What Reworks the never-merged [`backup-mariadb-e2e`](https://github.com/cozystack/cozystack/tree/backup-mariadb-e2e) branch onto the modern Chainsaw e2e approach ([`docs/agents/e2e-testing.md`](https://github.com/cozystack/cozystack/blob/main/docs/agents/e2e-testing.md)), rebuilt on fresh `main`. That branch bundled the whole MariaDB backup-strategy controller **plus** a `hack/e2e-apps/backup-mariadb.bats` test. The controller and the `examples/backups/mariadb/` manifests have since landed on `main` independently (`feat(platform): implement backup strategy for mariadb`), and the `hack/e2e-apps/*.bats` app suite has been replaced by `hack/e2e-chainsaw/`. So the only piece still missing was the e2e coverage — this PR delivers it the modern way. ## Changes - **`examples/backups/mariadb/` → executable harness.** Converts the demo from static numbered YAML into the same script harness the other backup demos use (`00-helpers.sh`, `run-all.sh`, `cleanup.sh`), keeping the numbered manifests as the human-readable flow that `run-all.sh` drives — so the documented flow and the automated test can never drift. `run-all.sh` provisions a `Bucket`, derives the two per-app Secrets the strategy references from `BucketInfo` + the seaweedfs CA, deploys a source MariaDB with a sentinel row, fires an ad-hoc `BackupJob`, restores to a copy with a to-copy `RestoreJob`, and asserts the sentinel round-tripped through S3 into the copy while the source is left untouched. - **`hack/e2e-chainsaw/mariadb/` → second Chainsaw Test** (`mariadb-2-backup-roundtrip`) that drives `run-all.sh` + `cleanup.sh`, following the merged `etcd-2-backup-roundtrip` harness-driving shape: runs in `tenant-root` (the isolated e2e tenant cannot reach `tenant-root`'s seaweedfs across the Cilium egress policy), `skipDelete` since the harness owns the resources, an idempotent pre-clean step so a run killed before `finally` cannot leave a stale `Succeeded` BackupJob that false-passes, fail-fast on terminal `BackupJob`/`RestoreJob` phases, and scoped `catch` diagnostics. Cleanup also prunes the operator-side `k8s.mariadb.com` `Backup`/`Restore` CRs the Cozystack jobs own only by label. - **`hack/select-e2e.sh` → TIA rule for `examples/backups/<app>/`.** The harness lives outside the suite dir, so without this a harness-only diff produced an empty selection, which `pull-requests.yaml` turns into "skip the whole E2E stage" — a future bug-fix to `run-all.sh` would merge with its own round-trip test never run. The new rule maps `examples/backups/<app>/` to the `<app>` suite that drives it (dir name == suite name for every backup demo except `vmi` → `vminstance`), with three cases added to `hack/select-e2e_test.bats`. ## Conventions followed - No retries on deterministic steps; the single `script` step carries a justified 30m budget (2 MariaDB instances × 310s first-boot startup probe + dump/restore) and fails fast rather than polling out. - Self-contained trap-based temp-file cleanup only inside a single step; no test-level EXIT trap. - Controller-created artifacts Chainsaw cannot reclaim are pruned explicitly by `cleanup.sh`. - TIA verified: `examples/backups/mariadb/run-all.sh` now selects the `mariadb` suite (`hack/select-e2e.sh`), and editing `select-e2e.sh` itself escalates this PR to the full suite. ## Downstream Repositories Walked the trigger map in `docs/agents/contributing.md` against the diff. The change touches only e2e test material, backup examples, and CI suite-selection — no package added/renamed/removed, no `values.schema.json` / `values.yaml` / platform-values / variant / `ApplicationDefinition` / namespace / release-asset changes, and no `hack/` file moved/renamed. No downstream repository is reached. - [x] `cozystack/website` — not affected (no package or platform/docs-source change) - [x] `cozystack/terraform-provider-cozystack` — not affected (no app/schema/enum/default/prefix change) - [x] `cozystack/ansible-cozystack` — not affected (no installer values / namespace / variant / node-prereq change) - [x] `cozystack/ccp` — not affected (no `hack/` move-or-rename, no make-target behavior change) ## Notes No `make generate` needed — the change touches only `examples/`, `hack/`, and a Chainsaw suite (the edited README is under `examples/`, not a package). ## Release note ```release-note Add an end-to-end Chainsaw test for the MariaDB backup/restore round-trip, and convert the `examples/backups/mariadb/` demo into an executable `run-all.sh`/`cleanup.sh` harness. ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added an end-to-end MariaDB backup and restore demonstration workflow. * Added automated backup round-trip validation, including data integrity checks. * Added reusable scripts for running the demo and cleaning up created resources. * Added automatic handling of backup credentials, endpoints, and trusted certificates. * **Documentation** * Expanded setup, configuration, execution, cleanup, and troubleshooting guidance. * Documented same-namespace restore support and cross-tenant limitations. * **Tests** * Added automated Chainsaw coverage for the MariaDB backup and restore workflow. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Cozystack
Cozystack is a free platform and framework for building clouds.
Cozystack is a CNCF Sandbox Level Project that was originally built and sponsored by Ænix.
With Cozystack, you can transform a bunch of servers into an intelligent system with a simple REST API for spawning Kubernetes clusters, Database-as-a-Service, virtual machines, load balancers, HTTP caching services, and other services with ease.
Use Cozystack to build your own cloud or provide a cost-effective development environment.
Use-Cases
-
Using Cozystack to build a public cloud
You can use Cozystack as a backend for a public cloud -
Using Cozystack to build a private cloud
You can use Cozystack as a platform to build a private cloud powered by Infrastructure-as-Code approach -
Using Cozystack as a Kubernetes distribution
You can use Cozystack as a Kubernetes distribution for Bare Metal
Documentation
The documentation is located on the cozystack.io website.
Read the Getting Started section for a quick start.
If you encounter any difficulties, start with the troubleshooting guide and work your way through the process that we've outlined.
Versioning
Versioning adheres to the Semantic Versioning principles.
A full list of the available releases is available in the GitHub repository's Release section.
Contributions
Contributions are highly appreciated and very welcomed!
In case of bugs, please check if the issue has already been opened by checking the GitHub Issues section. If it isn't, you can open a new one. A detailed report will help us replicate it, assess it, and work on a fix.
You can express your intention to on the fix on your own. Commits are used to generate the changelog, and their author will be referenced in it.
If you have a concrete feature request, open an issue. For a cross-cutting or architectural change, open a design proposal in the community repo. For questions or early ideas, use GitHub Discussions. See CONTRIBUTING.md for the full routing.
Community
You are welcome to join our Telegram group and come to our weekly community meetings. Add them to your Google Calendar or iCal for convenience.
License
Cozystack is licensed under Apache 2.0.
The code is provided as-is with no warranties.
Commercial Support
A list of companies providing commercial support for this project can be found on official site.