mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 5.5
ba8f4b5f3a
A local deploy stopped four times in two days in "Ensure Docker apt key and sources are consistent" (#849). apt_repo.sh downloads the Docker GPG key on every run, and when download.docker.com refused the connection, curl's four attempts were over within about six seconds and the script returned 1, although the key from an earlier run was installed and is all the following apt operations need. install_key now fails only when no key is installed. With a key in place, a refused download prints a warning and keeps it. A downloaded key that differs still replaces the installed one, and the 0644 mode is enforced in every case. The keyring path became an argument: ensure-key-and-sanitize passes the keyring it already hands to sanitize_sources, so the role's call still resolves to /etc/apt/keyrings/docker.asc, and a test can point the script at a temporary keyring. Verified: tests/unit/python/roles/sys-svc-container/files/test_apt_repo.py stubs curl and sudo. A refused download keeps the installed key and ends with changed=0, a refused download without a key exits 1, and a new key replaces the installed one. A copy of the script whose keep branch always errors, the old behaviour, fails the first test. Two local deploys ran the new script with rc 0 and an empty stderr and left the installed key untouched. shellcheck is clean. Not verified live: the refused download itself, which needs download.docker.com to refuse a connection during a deploy. A host without a key still needs the download and still fails when it is refused. Closes #849 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>