Run the end-to-end tests¶

Run a disposable Release 2 platform locally or inspect the same lab in GitLab CI. The lab installs OpenOP, exercises public APIs and backend resources, exports reports, and removes the infrastructure it created.

Before you start¶

Use Python 3, Git and a Docker daemon that can run privileged k3d nodes. Allow access to the ETSI repositories, release registry and provider images. The wrapper supplies the controller's Ansible, Helm, kubectl and k3d tools. Use an empty report directory for every run.

The published harness tag e2e-harness-v1.0.1 contains the frozen profile.release-2.0.json. That profile pins the Release 2 component sources and image digests, chart and SDK identity. The harness version and platform release are separate version numbers.

Steps¶

1. Get the published harness¶

git clone --branch e2e-harness-v1.0.1 https://labs.etsi.org/rep/oop/deploy/ansible.git
cd ansible

Read the operator guide for host requirements and the illustrated explanation for the execution flow. The local run creates its own disposable Kubernetes cluster.

2. Run the application variants¶

From the repository root:

sh ci/run_platform_lab.sh ci/lab/profile.release-2.0.json .cache/release-container-001

OOP_LAB_PACKAGE_TYPE=HELM \
  sh ci/run_platform_lab.sh ci/lab/profile.release-2.0.json .cache/release-helm-001

The first run tests a container workload; the second tests a Helm chart. Both runs check application registration, deployment, access endpoints and termination, including the resulting Kubernetes resources. They also verify which SDK is installed in the SRM image.

3. Run network coverage¶

OOP_LAB_NETWORK_PROVIDER=EURECOM \
  sh ci/run_platform_lab.sh ci/lab/profile.release-2.0.json .cache/release-network-001

This run starts EURECOM NEF/CoreSim and waits for a simulated device session. It tests QoD profiles and refusal paths, geographic location and device Traffic Influence, using the test application’s observed IPv4 endpoint. It checks provider-side resources and their cleanup.

The results qualify API and provider behaviour in this simulated setup. Radio QoS enforcement, physical location accuracy, packet steering, federation and other NEF implementations are outside this lab’s scope.

4. Inspect the CI run¶

To view the CI results:

Open the pipeline in the Ansible repository.
Open the release-feature-report job.
Read the summary and follow the links to the detailed reports.

To start tests from GitLab, follow the lab guide. It explains which branch or tag to use and which pipeline variables to set.

To test a new component image, follow the lab development guide.

Check it worked¶

Open the report directory passed to the command, for example .cache/release-container-001.

Evidence	What to inspect
`index.html`, `feature-matrix.md`, `feature-matrix.json`	Results by feature and links to the individual runs
`candidate.json`	The exact component sources, image digests and SDK identity tested
`result.json`	Setup, test execution and cleanup outcome
`health/junit.xml` or GitLab Tests tab	Individual test cases and failure details

Check that the required tests ran and passed, and that cleanup completed. The result applies to the component versions recorded in this run.

The wrapper removes the resources it created, including the Kubernetes cluster and provider containers. Reports remain in the selected report directory.

All options¶

See the operator guide for run options and profile overrides, the check catalogue for individual checks, and the SDK support matrix for supported capabilities and limitations.