recipe-maintainers/cc-ci-orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

upgrade-all: alternate heavy/light per wave (not heaviest-first)

Browse Source 
Host memory is the binding limit, so never schedule two HEAVY recipes in the
same capacity wave — pair each heavy (discourse/immich/matrix-synapse/
lasuite-drive/mattermost-lts/ghost) with a light one to bound peak memory while
keeping both slots busy. Heaviest-first could co-schedule two heavies and OOM/
wedge the box (the disc-50cc8a 'New'-state wedge). For CAP>2 cap heavies at
~CAP/2; if only heavies remain, run one-per-wave.
This commit is contained in:
autonomic-bot
2026-06-12 01:47:22 +00:00
parent a45517b432
commit f744c79e2d
1 changed files with 14 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
.claude/skills/upgrade-all/SKILL.md
View File

@ -156,10 +156,20 @@ with `/recipe-upgrade <recipe> --with-tests` to also get a verified test-update
- **Parallel (`--parallel`):** `CAP=∞` — emit ALL Agent calls in one message. Heaviest load;
failures still isolated per recipe.
Note (wave barrier): a wave waits for its slowest recipe before the next starts, so a slot can idle
if one recipe (e.g. discourse's multi-image upgrade) runs much longer than its wave-mates. That's
acceptable for the weekly run; do NOT try to maintain a rolling pool with `run_in_background` (you'd
lose the `RESULT:` lines). Order `RECIPES_TO_UPGRADE` heaviest-first so long upgrades start early.
**Wave composition — alternate heavy and light (do NOT just go heaviest-first).** The binding limit
is host memory, so never put two HEAVY recipes in the same wave: pair each heavy with a light one so
peak memory stays bounded while both slots stay busy. Classify from the survey's image set:
- **HEAVY** (multi-GB images / many services / slow deploy): discourse, immich, matrix-synapse,
lasuite-drive, mattermost-lts, ghost.
- **LIGHT / moderate** (one small image or a few light services): custom-html*, cryptpad, n8n,
uptime-kuma, lasuite-docs, lasuite-meet, keycloak, mailu, plausible.
Build the wave order by drawing one HEAVY + one LIGHT per wave (capacity 2) until a bucket empties,
then pair the remainder. For `CAP>2`, cap heavies per wave at ~`CAP/2`. If only heavies remain, run
them one-per-wave (effectively sequential) rather than risk an OOM.
Note (wave barrier): a wave waits for its slowest recipe before the next starts, so the light slot
idles while its heavy wave-mate finishes — accepted for the weekly run. Do NOT maintain a rolling
pool with `run_in_background` (you'd lose the `RESULT:` lines).
## 4. Collect results
Parse each final `RESULT:` line into SUCCESS / SUCCESS-PENDING-TESTS / FAILED / SKIPPED (default mode