Loading ci/lab/EXPLAINED.md +6 −2 Changes for ci/lab/EXPLAINED.md: 6 added lines, 2 removed lines. Original line number Diff line number Diff line Loading @@ -5,6 +5,8 @@ through one public API. For example: register a web application, start it in a chosen location, get its address, then ask the network to route a device's traffic towards it. E2E means end-to-end: following that whole journey through the running system. These tests act as that application owner. They run real OpenOP services in a small temporary Kubernetes cluster. They check public responses **and** what was actually created. A passing API response alone is insufficient. Loading Loading @@ -70,6 +72,8 @@ flowchart LR Registering an application records what to run. It does not start a container. These checks read the catalogue back and verify that deletion and rejected requests leave it in the expected state. Related negative checks also try unknown applications or instances and require the public API to reject them. ```mermaid flowchart LR Loading Loading @@ -115,8 +119,8 @@ flowchart LR A[Application owner] --> B[Public OEG network API] B --> C[SRM and TF-SDK] C --> D[EURECOM NEF and simulated device] D --> E[Read the created provider state independently] E --> F[Verify public and provider cleanup] D --> E[Check the response and any created provider state] E --> F[Remove owned resources and verify cleanup] ``` TI first needs the deployed application's observed endpoint. QoD and TI also Loading ci/lab/README.md +23 −0 Changes for ci/lab/README.md: 23 added lines, 0 removed lines. Original line number Diff line number Diff line Loading @@ -19,6 +19,29 @@ Counts at these two levels describe different observations, not extra features. Explanations come from source docstrings and link to the same revision as the run. No extra report service, Pages publication or manual reporting job is used. ## Harness map The shell wrapper owns the temporary controller and exports its reports. The Python controller owns the cluster and optional provider services. It calls the existing deployment and E2E playbooks; it does not duplicate their setup. ```mermaid flowchart TD A[ci/run_platform_lab.sh] --> B[ci/platform_lab.py in the controller] B --> C[r2_existing_cluster/deploy.yml] C --> D[ci/platform_smoke.py] D --> E[r2_existing_cluster/e2e.yml] E --> F[pytest cases selected by checkpoints.py] F --> G[Cluster and controller cleanup] G --> H[ci/feature_report.py finalizes each run] H --> I[ci/merge_feature_reports.py combines the three runs] ``` The feature renderer reads these actual receipts. It does not execute a second test suite or decide release approval. Shared fixture state keeps the same app alive between deployment, identity, endpoint and TI checks. Teardown still runs when a later assertion fails; cleanup is part of qualification. Run the same controller locally and in GitLab CI: ```sh Loading Loading
ci/lab/EXPLAINED.md +6 −2 Changes for ci/lab/EXPLAINED.md: 6 added lines, 2 removed lines. Original line number Diff line number Diff line Loading @@ -5,6 +5,8 @@ through one public API. For example: register a web application, start it in a chosen location, get its address, then ask the network to route a device's traffic towards it. E2E means end-to-end: following that whole journey through the running system. These tests act as that application owner. They run real OpenOP services in a small temporary Kubernetes cluster. They check public responses **and** what was actually created. A passing API response alone is insufficient. Loading Loading @@ -70,6 +72,8 @@ flowchart LR Registering an application records what to run. It does not start a container. These checks read the catalogue back and verify that deletion and rejected requests leave it in the expected state. Related negative checks also try unknown applications or instances and require the public API to reject them. ```mermaid flowchart LR Loading Loading @@ -115,8 +119,8 @@ flowchart LR A[Application owner] --> B[Public OEG network API] B --> C[SRM and TF-SDK] C --> D[EURECOM NEF and simulated device] D --> E[Read the created provider state independently] E --> F[Verify public and provider cleanup] D --> E[Check the response and any created provider state] E --> F[Remove owned resources and verify cleanup] ``` TI first needs the deployed application's observed endpoint. QoD and TI also Loading
ci/lab/README.md +23 −0 Changes for ci/lab/README.md: 23 added lines, 0 removed lines. Original line number Diff line number Diff line Loading @@ -19,6 +19,29 @@ Counts at these two levels describe different observations, not extra features. Explanations come from source docstrings and link to the same revision as the run. No extra report service, Pages publication or manual reporting job is used. ## Harness map The shell wrapper owns the temporary controller and exports its reports. The Python controller owns the cluster and optional provider services. It calls the existing deployment and E2E playbooks; it does not duplicate their setup. ```mermaid flowchart TD A[ci/run_platform_lab.sh] --> B[ci/platform_lab.py in the controller] B --> C[r2_existing_cluster/deploy.yml] C --> D[ci/platform_smoke.py] D --> E[r2_existing_cluster/e2e.yml] E --> F[pytest cases selected by checkpoints.py] F --> G[Cluster and controller cleanup] G --> H[ci/feature_report.py finalizes each run] H --> I[ci/merge_feature_reports.py combines the three runs] ``` The feature renderer reads these actual receipts. It does not execute a second test suite or decide release approval. Shared fixture state keeps the same app alive between deployment, identity, endpoint and TI checks. Teardown still runs when a later assertion fails; cleanup is part of qualification. Run the same controller locally and in GitLab CI: ```sh Loading
