Repository navigation
Run site.yml from CI, one box at a time, with lockout checks - #6
Merged
Merged
Conversation
site.yml now follows the same flow as platform.yml: the checks, a dry run of the merged commit written to the run summary, then the real run once a required reviewer approves it in `production`. When a merge touches both, site.yml goes first and platform.yml's dry run waits for it. Safeguards, since site.yml touches sshd, ufw, the admin keys and k3s: - production_rollout now governs site.yml too: one box per batch, and a failed box ends the run with the rest untouched. - After each box, whatever --tags ran: a fresh SSH login as the admin user with sudo, every key in admin_pubkey_file still in authorized_keys, and `sshd -t`. - CI sets site_require_hardened: a box that refuses the admin key fails the run rather than falling back to root, so CI never builds a box. - CI does not fetch kubeconfigs (k3s_write_local_kubeconfig), and the apt cache refresh no longer reports a change, so dry runs list real changes. scripts/ci-platform.sh becomes scripts/ci-playbook.sh <playbook> <mode>, and workflow_dispatch takes `playbook` and `run` instead of `platform`. Also fixes site.yml from a macOS controller: the local probe play cached the controller's Python as each box's interpreter. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
site.ymlnow runs from CI the same wayplatform.ymldoes. It needs no new secrets.routing.yml,bootstrap.yml,content.ymlandk3s-upgrade.ymldeliberately stay manual for now.What happens on merge
Once the checks pass, a dry run (
--check --diff) of the merged commit writes a per-box, per-task table to the run summary. The real run then waits for a required reviewer to approve it inproduction. If a merge touches both playbooks,site.ymlgoes first andplatform.yml's dry run waits until it has been applied. A failed or rejectedsite.ymlstopsplatform.yml. If a newer merge supersedes the pendingsite.ymlapply,platform.ymlstill goes ahead, so its change is not lost. For manual runs,workflow_dispatchnow takesplaybook(site/platform) andrun(none/check/apply), pluslimit.Safeguards against lockouts
production_rolloutnow governssite.ymlas well: one box per batch, and a box that fails ends the run with the remaining boxes untouched. I verified this in check mode by forcing a failure on sing-1; lith-1 and chic-1 never entered the play.--tagsran, and in dry runs too:ipniwithsudo -nadmin_pubkey_filestill inauthorized_keys(a negative test with a missing key fails as expected)sshd -ton the config sshd would load at its next startsite_require_hardened, so a box that refuses the admin key fails the run instead of falling back to root. I tested this with a bogus admin user.k3s_write_local_kubeconfig: false). The apt cache refresh no longer reportschanged. Together these keep the dry-run table limited to real changes.Current dry run (all three boxes, CI's vars, from this branch)
net.ipv4.ip_local_reserved_portsgains8000,8443(from Install Argo CD on lith-1 and open the ports monitoring needs #2) and9800-9801(from Reserve ports 9800-9801 for the monitoring Traefik #5), which never reached the boxes. Reserving a port only affects how the kernel picks outbound source ports, so existing listeners and connections are untouched.Nothing changes in sshd, ufw or k3s, and there are no restarts. This merge will offer exactly this apply.
Other changes
scripts/ci-platform.shbecomesscripts/ci-playbook.sh <site|platform> <check|apply> [limit].site.ymlfrom a macOS controller: the local probe play cached the controller's Homebrew Python as each box's interpreter.production_rolloutcomment are updated.Known trade-off
site-mainandplatform-mainare separate concurrency groups, so asite.ymlapply and aplatform.ymlapply from different merges can overlap. A single shared group would let one playbook's newer merge cancel the other playbook's pending apply. This is documented in the README.Lint: yamllint, ansible-lint (production profile, 0 failures), syntax-check of all six playbooks, shellcheck and actionlint all pass locally.
🤖 Generated with Claude Code