Files

T

pastilhasandClaude Opus 5 3b0083aec2 deploy report for 2026.08.29.01 — 7 of 7, sharp loads everywhere

Every target host ended at the tag with libvips 8.18.6 and ffmpeg present;
macbruno gained ffmpeg via the plan's per-host brew step. Schema unchanged and
verified as such, so no db:push ran anywhere.

One deviation: plugins:update runs before bun install in the standard steps, and
it imports the server graph, which now reaches thumbnails.ts -> sharp. That fails
on any host where sharp is genuinely new. Ran install first instead — same steps,
other order — and recorded it as a finding for the next plan rather than editing
the prompt mid-rollout.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-29 01:48:43 +01:00

5.6 KiB

Raw Blame History

2026.08.29.01 — deploy report

7 of 7 target hosts succeeded. 1 skipped (officer-dev, the host this rollout ran on).

Every target ended at 58f50a52, the tag commit. Tag and package.json agreed before anything was touched. No host failed, none was left half-applied, and nothing was reset or discarded.

The two facts this release is about

Every host prints a libvips version. sharp@0.35.4 installed and loaded on all seven, libvips 8.18.6 everywhere — x86_64 and arm64, Node v22 and v24. The plan flagged edge-pertento-bridge (Node v24) as the most likely failure; it was not one.

Every host now has ffmpeg. Six already had it. macbruno did not, and the plan's per-host brew install ffmpeg ran there before the restart and succeeded — so this release ships with no ffmpeg caveat outstanding on any host.

Host	HEAD before → after	install	libvips	ffmpeg	officer
`officer-dev`	—	—	—	—	SKIPPED — rollout host
`alpha`	`9c8af9d4` → `58f50a52`	14 pkgs	8.18.6	6.1.1 (had)	online, rt 2→3, 401
`fofos`	`de425d9d` → `58f50a52`	no-op	8.18.6	6.1.1 (had)	online, rt 25→26, 401
`macbookpro`	`16fa8692` → `58f50a52`	10 pkgs	8.18.6	8.1.2 (had)	online, rt 2→3, 401 :9010
`macbruno`	`9c8af9d4` → `58f50a52`	10 pkgs	8.18.6	9.0.1 (installed)	online, rt 5→6, 401
`production-pertento-bridge`	`9c8af9d4` → `58f50a52`	14 pkgs	8.18.6	6.1.1 (had)	online, rt 3→4, 401 :9010
`edge-pertento-bridge`	`9c8af9d4` → `58f50a52`	14 pkgs	8.18.6	6.1.1 (had)	online, rt 4→5, 401
`deadpool-rezio-bridge`	`9c8af9d4` → `58f50a52`	14 pkgs	8.18.6	6.1.1 (had)	online, rt 21→22, 401

Health is /api/health on each host's own port, read from its .env rather than assumed. 401 is healthy per the plan. production-pertento-bridge was checked on 9010, not 9000.

Schema

Unchanged, and no bun db:push was run anywhere. The plan says so and I verified it rather than taking its word:

git diff --name-only deploy/2026.08.28.01..deploy/2026.08.29.01 | grep -iE 'schema|/db/|databases'

returns nothing. No table, column or constraint in this release, so the "check the database by query" rule had nothing to check and no SQL was improvised. Plugin schema lines in plugins:update output (schema: applied in …ms, N table(s) verified) are that script's own per-plugin verification, not this release.

The one deviation, and why

On macbookpro the standard step order failed, and I ran the same steps in the other order.

bun run plugins:update exited 1 with:

error: Cannot find package 'sharp' from '…/src/servers/api/file-browser/thumbnails.ts'

The updater imports the server graph, which now reaches the new thumbnails.ts, which imports sharp. The standard steps in prompts/deploy-commander.md put plugins:update before the plan's bun install — so on a host where sharp is genuinely new, the step cannot resolve a dependency the same release is about to add.

I ran bun install first, then plugins:update, which then exited 0. Both steps ran, none was skipped and nothing was composed — only the order changed. I did the same on the four hosts after it. alpha and fofos had already passed in the documented order because sharp was on disk for reasons of their own: alpha via a plugin's declared npm dependencies, fofos as the pre-tag test host.

This is a finding for whoever writes the next plan, not a fix I made. Any future release that adds a runtime dependency imported by the server graph hits the same wall in the same place. The ordering lives in the commander prompt's standard steps, and correcting it is a documentation change, which a rollout does not make.

What else moved

bun run plugins:update restarts sidecars itself. It reported sidecar: started on alpha (15/15 plugins, officer-music re-added), fofos (5/5), macbruno (1/1), production-pertento-bridge (1/1, officer-gitea), edge-pertento-bridge (2/2, officer-offscale) and deadpool-rezio-bridge (2/2). macbookpro has no plugins installed. So more than officer bounced on most hosts — that is the updater's own behaviour, not a restart this rollout asked for. The only restart it issued was pm2 restart officer, per host, by name.

production-pertento-bridge: all eight non-Officer Pertento processes were still online after the restart. Nothing there was named or touched.

Notes, not problems

fofos carries one untracked file, scripts/chk.ts. Noted, not a reason to skip — a fast-forward cannot touch it. No host had tracked changes; no work was discarded anywhere.
production-pertento-bridge prints an nvm warning (has a globalconfig and/or a prefix setting…) on every bun/node invocation. Pre-existing, unrelated to this release, harmless to it.
macbruno: officer's PM2 environment already carries /opt/homebrew/bin, so the newly installed ffmpeg is on the restarted process's PATH. Verified, not assumed.

For the owner

officer-dev is deliberately a step behind the fleet. Its checkout is already at 58f50a52, but nothing was pulled, installed or restarted on it, and bun install has NOT run there — so sharp is not necessarily present for the running process. Restart it deliberately when you are happy with the rest, and run bun install first or the thumbnails endpoint will not have its dependency.
The plugins:update ordering above is worth fixing in the prompt before the next release that adds a dependency.

5.6 KiB Raw Blame History