Run in CI

The execution server you deploy for remote execution can also run one suite or one chain and exit, with no desktop application and no interface.

How it works

The container is the same one you run as a long-lived execution server. Set one environment variable, VP_RUN, and instead of staying up it runs what you named, writes its results, and exits with a code your pipeline can branch on. Leave VP_RUN unset and it behaves as an ordinary server.

Choose what to run

Set VP_RUN to a suite or a chain:

`VP_RUN`	Runs
`suite:<name or id>`	A test suite
`chain:<name or id>`	A single chain

A name is resolved inside your workspace. An id is matched first, then a unique name. If a name matches more than one thing the run stops and asks you to name it by id, rather than guessing which you meant.

Point it at your tests

Your tests live in a directory-backed workspace, a folder you keep under version control. Mount that folder into the container and name it with VP_WORKSPACE_DIR. A read-only mount is fine, because the run does not write back into it.

Variables and secrets

Name an environment with VP_RUN_ENV and the run starts from that environment’s variables. Add or override values with VP_RUN_VARS, a list of key=value pairs separated by newlines or semicolons, which win over the environment.

A headless run does not apply an environment’s stored credential bindings, so a credential the run needs has to be supplied at run time. Mount a JSON file and name it with VP_CREDENTIALS_FILE, or pass one or two values as VP_CREDENTIAL_<NAME>_<FIELD>. Wiring it into your CI server has working examples of both.

Keep secrets out of VP_RUN_VARS. A run’s variables are part of its record: they stay in the run history and they are written into evidence.json, so a value passed that way can be read back from the output directory after the run. Credentials supplied the way above never reach the run’s variables, so they appear in neither. VP_RUN_VARS is for values a run needs and nobody minds reading, such as a base URL or a build number.

Read the result

The exit code is the verdict:

Code	Meaning
`0`	Passed, and at least one assertion was checked
`1`	An assertion failed
`2`	Could not run: no such suite or chain, a bad selector, or a setup step that failed
`3`	Nothing was asserted, so there is no verdict to trust
`4`	Your license does not allow what you asked to run

A probe that reaches its target and finds nothing still counts as a successful request, so a run that asserts nothing can look green while testing nothing. VirtuProbe reports that as inconclusive, so a pipeline gate cannot pass on a test that checked nothing.

Set VP_OUTPUT_DIR and the run writes two files there:

junit.xml, the JUnit report your CI system reads to show passes and failures.
evidence.json, the full record of the run for a report or an audit trail.

Example

docker run --rm \
  -e VP_RUN=suite:checkout-smoke \
  -e VP_RUN_ENV=staging \
  -v "$PWD/workspace:/workspace:ro" -e VP_WORKSPACE_DIR=/workspace \
  -v "$PWD/results:/out" -e VP_OUTPUT_DIR=/out \
  virtuprobe-execution-server

This runs the checkout-smoke suite against the staging environment, using the workspace mounted read-only at /workspace, and writes results/junit.xml and results/evidence.json. The container exits 0 if the suite passed. Replace virtuprobe-execution-server with the execution server image for your deployment.

Getting the image

The execution server ships as a container image. It is not published for anonymous download: access is granted per customer as part of an Enterprise deployment, so that the image can be placed wherever your environment needs it, whether that is a registry you already run, credentials scoped to your own account, or an offline archive for a disconnected network.

If you are evaluating VirtuProbe and want to run it in a pipeline, ask us and we will sort out access for your environment.