Repository navigation
merge queue: checking #386 on main (f41b6d6) - #391
Closed
mergify[bot] wants to merge 2 commits into
Closed
mergify[bot] wants to merge 2 commits into
mergify[bot] wants to merge 2 commits into
Conversation
…ase on its own, between phases `catalyst runner update` reads the release Catalyst approved for self-hosted machines (GET /api/v1/hosts/desired-release, read with the host's own credential from inside a one-off supervisor container, so the secret never leaves Docker). It moves only when the release parses strictly (three digests from the three Catalyst repositories, never a tag or latest, release id matching the digests, a generation newer than the last applied), no phase container exists for this host, all three images pull natively by digest, and, on a Mac with private thoughts storage, that storage re-attests on the new supervisor with the same authority. Between phases is enforced, not sampled: after the pulls it stops the supervisor so it admits nothing, looks again, and if a phase started in between it brings the supervisor back on its old images and waits. A release counts as applied only when the running containers are its images and the supervisor logged host_ready since it started, so a .env an interrupted run left behind is reconciled, never trusted. Every path that does not end on the new release attests Mac thoughts storage back onto the images the machine keeps. The lock is taken over only when its owner process is gone. Then it rewrites only the three image lines in .env (keeping the previous file as .env.release-previous), runs docker compose up, and waits up to five minutes for the new supervisor to log host_ready. If it does not, the previous file and images come back and the run exits 1. Every other answer keeps the current images. release-state.json records the applied generation and the last outcome. After a verified update it removes the images it replaced (a runner image is about 9 GB against the 25 GiB free-disk floor); a rollback or failure keeps them. `catalyst runner auto-update on|off|status` schedules the check every 15 minutes (a LaunchAgent on macOS, on calendar minutes 0/15/30/45 because a StartInterval job sat pended for hours on a busy Mac, a systemd user timer on Linux, which says when lingering is off). Setup turns it on after the runner starts; a failure there is reported and never fails setup. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LGe7UXEGNZW1GenNuUZRDU Change-Id: I9624b6ebe5c2ca63f14cb48f9fff34e2deaec99f
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.
Note
This is a merge queue draft opened by Mergify. Nobody needs to act on it.
Mergify opened it for batch maxed-coing-f89u5z of the
defaultqueue, to test #386 before it merges intomain. Pushing to this branch or closing this pull request removes #386 from the queue.What this draft tests
Mergify checks that #386 still passes CI on top of
main. CI runs on this draft's code, built in this order:mainatf41b6d6🎉 Where it stands: checks passed
CI passed on this draft.
Follow the
defaultqueue in the dashboardWhat happens next
mainand closes this draft.Metadata for CI tooling, read by
mergify ciRequired conditions of queue rule
defaultfor merge#review-threads-unresolved=0base=maincheck-success=checklabel!=holdno unresolved review threads before merge]:#review-threads-unresolved=0Required conditions to stay in the queue
#review-threads-unresolved=0-draftbase=maincheck-success=checklabel!=holdno unresolved review threads before merge]:#review-threads-unresolved=0