branderson
7816bb7834
A runner VM is pinned to the day it was built, with half its controls typed into a hypervisor console no `git pull` can reach. dejima needs nothing like this - short-lived containers, only the tip of main supported, a pull closes any gap - and the difference is worth stating rather than inheriting. AND THIS PROJECT HAS A SECOND WAY OF GOING BACKWARDS that the sister project does not: the scheduled rollback. A guest-side change applied to a running runner and never baked into the snapshot is undone at the next rebuild, on a timer, with nothing to see. So a guest-layer upgrade here is a seven-step sequence, and `status` prints it whenever one is outstanding rather than leaving it to be remembered. The counter-intuitive step is rolling back to the clean snapshot BEFORE applying the change, so the new rollback target is not whatever the last few weeks of jobs left behind. The state file lives in the guest, inside the snapshot, so it rolls back with everything else. That is correct rather than unfortunate: forget to re-snapshot and the marker reverts alongside the change it recorded, so the tool goes back to reporting the upgrade as outstanding. It fails towards saying there is work to do. Integer versions, one note per version including versions that need nothing. Two numbers tracked: guest_version written by install.sh, node_version asserted by an operator, because nothing in the guest can read the hypervisor's rules - which is what makes those rules the boundary. TIER IS RECORDED, NEVER DETECTED. An absent /etc/dejima-ci/config identifies a privileged host correctly and also identifies a confined one whose install.sh has not run, and guessing wrong selects a different set of upgrades - the same failure test/ci-runner.bats takes DEJIMA_CI_TIER rather than sniffing for. The privileged tier reports no guest half at all rather than an unrecorded one, since installing nothing there is the grant that tier exists for. `check-lan` gives mark-node something to contradict a wrong assertion with: it asks ff02::1 who is on the link and counts the replies that are not this VM's own. It is a narrow test of one node rule, not the in-VM audit that PR #18 said was out of scope, and the docs say so where an asymmetry with the sister project would otherwise look like parity. v2 needs node work only, so it asks for no re-snapshot. A test pins that, because reporting the sequence when it does not apply would train an operator to ignore it when it does. Tested with `bats test/` (125 passing, up from 100).
2 lines
2 B
Plaintext
2 lines
2 B
Plaintext
2
|