Demo environment acceptance testing

This is developer and release-validation documentation. Routine administration is in Managed demo environments.

Public disposable acceptance server

Acceptance uses a public disposable server because real DNS, Dokku deployment, Let's Encrypt, PostgreSQL/PostGIS, mounted storage, and HTTPS must be exercised. The server must contain no production applications, credentials, data, routes, webhooks, or external-write integrations.

The workstation needs SSH access as a named administrator with passwordless sudo, plus a public key registered with Dokku. The server needs Dokku 0.38.22 or later with equivalent named-storage behavior, PostgreSQL/PostGIS, an empty protected demo_template, a private demo storage root, wildcard public DNS, ports 80/443, and the Dokku Let's Encrypt plugin.

No registry, provisioner, installed helper, server checkout, release mirror, delegated SSH account, or restricted-command sudo rule is used. The named administrator instead has the unrestricted passwordless sudo access documented in the installation guide.

Automated local tests

From the repository root:

/home/assela/python/.venv/bin/python -m unittest discover \
  -s tests/demo/unit -t . -p 'test_*.py'

/home/assela/python/.venv/bin/python -m unittest discover \
  -s tests/demo/integration -t . -p 'test_*.py'

Run the targeted Django tests with the disposable PostGIS test settings described in specs/016-simplify-demo-management/quickstart.md.

Owner-authorized live lifecycle

Use only the reserved canonical name demo_acceptance. Obtain explicit project-owner approval before any live/destructive run. Validate create, administrator login, tutorial workflow data, list, status, update, reset, repeated delete, missing-anchor cleanup, conflicting-marker retention, HTTPS, and exact deployed commits using the quickstart.

Interruption matrix

The acceptance-only failpoint mechanism is disabled by default. It activates only when all three conditions hold:

  • DEMO_ACCEPTANCE_APPROVED=yes and the runner's --approved option are present;
  • the exact target is demo_acceptance; and
  • the stage is one of the ten allowlisted post-stage boundaries.

Run from an interactive workstation terminal because each create prompts for a unique password:

DEMO_ACCEPTANCE_APPROVED=yes \
tests/demo/acceptance/run_interruption_matrix.py \
  --approved \
  --host assela@demo-server.example.org \
  --release APPROVED_40_CHARACTER_COMMIT

For every stage the runner expects create to fail, then performs confirmed deletion twice. After the matrix, create the same name normally to prove reuse. The failpoint selector is non-secret and may be passed to the transient coordinator; application and database secrets must remain absent from argv, environments, output, and journald.

Secret-canary review

Use unique canaries in the instrumented fake tests. Inspect workstation and remote argv/environment snapshots, Git/Dokku output, PostgreSQL diagnostics, application command output, lifecycle text/JSON, and:

ssh assela@demo-server.example.org \
  sudo -n journalctl -t lmstool-demo-manager --since today

No canary or complete credential-bearing URL may occur. Confirm the temporary administrator password file is absent after success and injected failure.

Record the commands, dates, test counts, retained resources, certificate delays, responsiveness results, and project-owner approval under specs/016-simplify-demo-management/evidence/.