Three containers.
Nine scan
results.

Check the license.
Before scanning a project.

cpptest-license-features queries the license configured for a specific C/C++test CLI. No project analysis is performed.

A preflight check, not a capacity test. The utility does not prove three available server allocations or nine simultaneous analyses. Use the same container image and approved license settings as the scans.

Query the lab installation.
Review the feature list.

ESL supplies the utility separately. Run it in each target container environment before the verification scans.

# Set these paths for the actual installation and approved settings
./cpptest-license-features "$CPPTEST_PROBE_CLI" \
  --settings "$CPPTEST_SETTINGS" --json > license-features.json

Compatibility gate: uses undocumented -check-license, verified on Windows 2025.1 and Linux 2025.2, not Xsight's 2023.1.1 image. Linux 2025.2 needs cpptest/bin/cli/cpptestcli, not its top-level launcher. Confirm the probe path/support with Parasoft for the lab version; keep the existing scan command unchanged.

Same workload.
More scans at once.

After license preflight, use the nine-app project to verify the move from one scan per container to three independent scan processes.

Scheduling illustration only. Both modes produce nine reports in total. This is a concurrency target, not a measured 3× speedup. The baseline switch limits scheduling; it does not change the installed license edition.

Three Automation allocations.
Nine independent processes.

Intended allocation, verified during the run. The License Server grants licenses; the demo does not assign, duplicate or spoof machine IDs.

Nine C++17 applications.
Nine distinct defect combinations.

Three related variants per family. Small enough to inspect, different enough to distinguish the results.

The runner builds and analyzes these programs; it never executes their defective paths. These are intended defects, not promised detection counts. Findings depend on the scanner version and enabled rules.

Keep your toolchain.
Isolate each scan.

Adapted from the Dockerfile, properties and analysis script supplied by Xsight Labs.

C/C++test Standard is a product name. Automation is a licensed capability. The demo retains the supplied Standard CLI command pattern and requests the approved server edition.

Prepare. Launch. Observe.

After reviewing the utility's feature list, run the test project on the Xsight lab server in a reserved test window.

# Optional baseline: one scan at a time in each container
python3 lab.py run --mode standard

# Automation target: three scans at a time in each container
python3 lab.py run --mode automation

Tiny-sample defaults: 3 CPUs and 10 GiB limit per container, 2 GiB Java heap per scan. Reserve additional host/native-engine headroom. These are starting values, not production sizing.

Nine reports.
A traceable run summary.

Keep each preflight JSON alongside the scan evidence. Results stay on your server, not in this public presentation.

Expected findings are not scanner failures: exit 2 with -fail is accepted. License errors, setup failures, timeouts and missing or empty reports fail the technical check.

Choose the DTP view.
Keep all nine result sets.

Group by container for a compact view, or by application for individual project tracking.

A shared build.id identifies the run; a unique session.tag identifies each scan. Approve the demo projects, then set DTP_PUBLISH=true. Dashboard aggregation does not change the nine local report directories.

Prove execution.
Confirm the granted licenses.

The utility checks available features first. The test project and live License Server evidence verify the three-by-three configuration.

Process overlap alone is not proof of licensed engine overlap. Capture token details while the jobs are active. A requested feature list does not establish what the License Server granted.