Files
computer-playbook/docs/contributing/tools/github
kevinveenbirkenbachandClaude Opus 5 9aa65a7731 fix(web-app-docs): replay the published instructions against a server, not against the recipe container
The harness rewrote HOST to localhost, and the provisioner turns localhost into ansible_connection local, so the replayed deploy configured the throwaway container the recipe starts rather than any server. PID 1 there is the entrypoint, not systemd, and sys-svc-container refused with "PID 1 is infinito, not systemd" in all five rows that deploy web-app-docs alongside their own role.

The block now runs on the stack host and deploys over ssh into a target container that carries systemd and an ssh server and nothing else. sshd.sh installs that server and authorizes the key pair the run generates; machine.sh reads the target bridge address with container inspect, substitutes it for HOST, and only then runs the placeholder guard, because the address does not exist before that point. The target joins the default bridge so the recipe nested docker run can reach it, and that bridge has no DNS, so the value is an address.

PREPARE and engine.sh both fall away. The target is bare on purpose: the replayed deploy installs docker-ce itself, which is the claim under test, so the restart collision engine.sh worked around can no longer occur. Its /var/lib/docker stays a named volume so the installed daemon writes to a real filesystem instead of stacking fuse-overlayfs on fuse-overlayfs.

A shape guard refuses a block that starts no container, because this harness would otherwise configure the stack host itself; that guard was exercised in both directions. Teardown now also removes the generated key pair and the inventory the recipe writes, the latter only when the run created the directory. A schema in the test folder documents the flow.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-10-16 21:49:41 +02:00
..
…

GitHub governance guides 🛡️

This directory contains contributor guidance for GitHub governance and repository controls. Its scope is branch protection, repository settings, GitHub Actions workflows and variables, and other platform rules that affect contributions.