See what your commands do on Ubuntu.

Run your application’s tests, workers and build commands inside an Ubuntu container and keep their output for comparison. Your agent can spot a changed result even when every command succeeds.

DockerUbuntu · release checkRecorded plugin output
Captured release checkLine 8 · selected step
  1. # Before · main
  2. container.bash command="./bin/test"
  3. # After · PR · same commands, fresh container
  4. container.bash command="./bin/test"

Recorded plugin invocations shown in flow syntax. Checkpoint names label this presentation; the capture used the plugin host directly, not reflow apply. Select a checkpoint line to inspect its output; preceding lines provide context.

Output · selected step

Real plugin output, synthetic shop app. IDs shortened, setup flags abbreviated. Driven directly through the plugin host; checkpoint names below are presentation labels, not stored Reflow checkpoints. Full capture and fixture source

ContainerYour test setup
$ docker build -q -t shop-test:pr . sha256:b83b8cfb3206 $ docker run -d --network=none --name shop-test-pr shop-test:pr d2c3ea9cda2a

Connected shop-test-pr · /workspace

Snapshot · release-package · beforemain · presentation label
› container.bash command="./bin/test" shop 1.4.0 tests on Ubuntu 24.04.5 LTS ok - full refund returns the payment ok - half refund splits the payment ok - free order refunds nothing 3 passed › container.bash command="./bin/package" files="[\"dist/release.env\"]" packaged dist/shop-1.4.0.tar.gz dist/release.env: 4 settings
tests
exit 0stdout.txt 153 Bstderr.txt 0 B
release-package
exit 0stdout.txt 61 Bstderr.txt 0 Bfiles/dist/release.env 68 B
files/dist/release.envsha256 9f564b64
CURRENCY=USD
LOG_LEVEL=warn
RECEIPT_EMAILS=on
REFUND_WINDOW_DAYS=30
Snapshot · release-package · afterPR · presentation label
› container.bash command="./bin/test" shop 1.4.0 tests on Ubuntu 24.04.5 LTS ok - full refund returns the payment ok - half refund splits the payment ok - free order refunds nothing 3 passed › container.bash command="./bin/package" files="[\"dist/release.env\"]" packaged dist/shop-1.4.0.tar.gz dist/release.env: 4 settings
tests
exit 0stdout.txt 153 Bstderr.txt 0 B
release-package
exit 0stdout.txt 61 Bstderr.txt 0 Bfiles/dist/release.env 68 B
files/dist/release.envsha256 634287c8
CURRENCY=USD
LOG_LEVEL=warn
RECEIPT_EMAILS=on
REFUND_WINDOW_DAYS=14
Delta · release-packageBefore · main → After · PR
  • tests Unchanged, 3 passed
  • release-package State and evidence changed
files/dist/release.envsha256 9f564b64 → 634287c8
Before- REFUND_WINDOW_DAYS=30 After+ REFUND_WINDOW_DAYS=14

Exit code 0 → 0 · stdout.txt and stderr.txt unchanged

Both retained files
main
CURRENCY=USD
LOG_LEVEL=warn
RECEIPT_EMAILS=on
REFUND_WINDOW_DAYS=30
PR
CURRENCY=USD
LOG_LEVEL=warn
RECEIPT_EMAILS=on
REFUND_WINDOW_DAYS=14
Agent’s review note · example

“Both runs succeed, but the package now ships a 14-day refund window instead of 30. The PR comment says the shorter window is for local test fixtures. Should production keep 30?”

Run inside the container your setup provides.

Start a test-owned Ubuntu container with your application inside, then point the flow at it. Each command runs in the configured working directory, and Reflow retains its stdout, stderr and exit code, with up to two selected files. Images, mounts and networks stay with your setup, and the container keeps running afterwards.

  • Stdout and stderr from inside the container
  • Exit code
  • Up to two selected files

Compare the files a command leaves behind.

Retained output and selected files are compared byte for byte across runs. A packaging command can succeed twice while the settings file it writes has changed.

In the example, the tests and the package command succeed in both runs, but the packaged production settings now allow refunds for 14 days instead of 30. Your agent can bring both retained files into its review and ask whether the refund policy was meant to change.

Bring the evidence into PR review

Your test and build commands, in a container

Keep the container name and its absolute working directory in the private DockerUbuntu connection. The container must already be running Ubuntu with Bash and your application installed; the example uses the fixture’s ./bin/test and ./bin/package.

Your agent can inspect the installed plugin’s commands and write the flow using your application knowledge. Select the plugin version in the flow’s requirements.

Flow excerptDockerUbuntu
---
providers:
  container: DockerUbuntu
---

container.bash command="./bin/test" checkpoint="tests"
container.bash command="./bin/package" files="[\"dist/release.env\"]" checkpoint="release-package"

Plugin requirements and private connection settings are configured separately.

Check the rest
of the application.