Skip to content

merge queue: checking #386 on main (f41b6d6) - #391

Closed
mergify[bot] wants to merge 2 commits into
mainfrom
mergify/merge-queue/e5b00ef169
Closed

mergify[bot] wants to merge 2 commits into
mainfrom
mergify/merge-queue/e5b00ef169

Conversation

@mergify

@mergify mergify Bot commented Oct 17, 2026 •

Copy link
Copy Markdown
Contributor

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 default queue, to test #386 before it merges into main. 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:

  1. main at f41b6d6
  2. #386, the pull request of this batch

🎉 Where it stands: checks passed

CI passed on this draft.

Follow the default queue in the dashboard

What happens next

  • Mergify merges #386 into main and closes this draft.
Metadata for CI tooling, read by mergify ci
---
all_scopes: false
checking_base_sha: f41b6d6daf17ab1e625197ede276ef7ff60805f6
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 386
    scopes: []
scopes: []
...
Required conditions of queue rule default for merge
Required conditions to stay in the queue

ryanrozich and others added 2 commits October 17, 2026 08:33
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant