kevinveenbirkenbachandClaude Opus 5 5005c3962a fix(workspace): keep the onion out of the matomo deploy ...

02_performance deployed matomo with no disable set at all, so svc-net-tor joined the groups. It is exclusive, matomo follows it through tor.enabled in its own services meta, and the clearnet vhost disappears. The assertion two lines down then aborts in TLS before HTTP: 'curl: (35) TLS connect error: tlsv1 unrecognized name', reported as '[FAIL] https://matomo.infinito.example returned HTTP 000, expected 200'.

The counter-example sits in the same job: 01_minimal deploys dashboard with the group-conditional services disabled, tor among them, and its clearnet assertion returns 200. This suite tests the inventory, not the transport -- that a dedicated deploy replaces the previous app set. So it takes the route the sibling script already proves, rather than asserting against an onion address the runner never touched.

03_reuse stays untouched: it runs mode=update against the inventory 02 just built.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-16 03:38:38 +02:00

..

01_minimal.sh

refactor(workspace): split the environment suite into base, compose and swarm tracks

2026-08-10 22:57:05 +02:00

02_performance.sh

fix(workspace): keep the onion out of the matomo deploy

2026-08-16 03:38:38 +02:00

03_reuse.sh

refactor(workspace): split the environment suite into base, compose and swarm tracks

2026-08-10 22:57:05 +02:00

04_teardown.sh

fix(workspace): give the swarm track the teardown boundaries the old suite had

2026-08-10 23:44:11 +02:00