Continuous Verification⚓︎
Before any procedure in the acceptance test catalog is run by a person, the platform has already been installed, provisioned, driven with subscriber traffic, broken and repaired by automation. This section publishes what that automation is, what it asserts and how often it runs, so that an MNO can weigh the manual catalog against the verification that precedes it.
What runs, and when⚓︎
| Check | What it is | Cadence |
|---|---|---|
| Component tests | Unit and component suites in each repository: the xControl services against a real PostgreSQL 17 database, the session-management function, the Kubernetes operator for the core, the xControl front end | Every merge request in the owning repository |
| Platform end-to-end suites | Six suites that install xControl, xView and the cores from the published Helm charts into a fresh namespace on a Kubernetes cluster, provision a tenant through the xControl API, drive sessions with 3GPP peer simulators, inject faults and verify the cluster is left clean | Every merge request to the platform verification repository; a weekly deep soak of every session flow and the capacity ramps |
| xControl browser suite | Real Chromium browsers driving the xControl portal against a real backend and front end | On demand from the front-end pipeline, before an xControl release |
| Release certification | A harness that applies a declarative core configuration to a real cluster, waits for it to converge, and drives subscriber lifecycle scenarios through the simulator, producing one JUnit verdict per configuration | Before a release is published |
| Supply-chain checks | Image provenance and pull-policy validation and vulnerability scanning in the platform suites; software bills of materials on every release tag | Every platform suite run; every release tag |
What a failure does⚓︎
A failing component test or platform suite blocks the merge request that caused it. A failing weekly soak is reported to Engineering with the soak's full report and the captured diagnostics. A failing certification run is a no-go for the release. Every finding fails the run that produced it; findings are tracked as work items in the verification repository until they are fixed, so none is silently ignored.
Diagnostics on failure⚓︎
When any platform-suite test fails, the framework captures the state of every managed namespace (pods, container logs, events) into the run's report before teardown, so a failure can be analyzed without reproducing it. Soak and capacity runs write their full report and a memory summary before any verdict is asserted, and a run that detects a wedged component can be configured to leave the cluster in place for diagnosis instead of tearing it down.
Where the results are⚓︎
Results are GitLab pipeline artifacts: JUnit reports per suite, the soak and capacity reports, Trivy scan reports, browser traces and videos. They are not public. An MNO evaluating a release can request the pipeline summary and the certification verdict for that release through its Expeto account team.
Names used in this section⚓︎
The platform verification framework is Expeto's own and is referred to by its internal name, Canopy, where the distinction from the browser suite matters. The xControl browser suite lives in the front-end repository (internal name Spruce). The 3GPP peer simulator that plays the radio and the peer core in both the platform suites and release certification is referred to as the simulator (internal name hickory). No other internal names appear in this documentation.