recipe-maintainers/cc-ci-orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
dc6aa1c2c41e038e6831c843d19cf0e11b902e17
cc-ci-orchestrator/cc-ci-plan/upstream/immich.md
T

8.8 KiB
Raw Blame History

Upstream sources — immich

service image source repo releases / changelog
app ghcr.io/immich-app/immich-server https://github.com/immich-app/immich https://github.com/immich-app/immich/releases
immich-machine-learning ghcr.io/immich-app/immich-machine-learning https://github.com/immich-app/immich https://github.com/immich-app/immich/releases
redis docker.io/valkey/valkey https://github.com/valkey-io/valkey https://github.com/valkey-io/valkey/releases
database ghcr.io/immich-app/postgres https://github.com/immich-app/base-images https://github.com/immich-app/immich/blob/main/docker/docker-compose.yml

Standing notes

  • DB image is pinned BY immich-server, not bumped independently. abra cannot survey/upgrade this recipe (FATA … Docker references with both a tag and digest are currently not supported) because database is pinned image:tag@sha256:…. Use the box-item-4 direct check: the authoritative source for the DB tag is immich's own docker/docker-compose.yml at the immich-server release tag (https://raw.githubusercontent.com/immich-app/immich/<vX.Y.Z>/docker/docker-compose.yml). Pin the recipe's database image to EXACTLY what that compose pins for the matching immich-server version — do NOT take the newest ghcr.io/immich-app/postgres tag. Newer tags (pg-15/16/17/18, vectorchord0.5.x, pgvectors0.3.0) exist but moving ahead of what immich-server ships forces a pg-major data migration and an unsupported extension combo.
  • immich-server v3.0.3 (latest, 2026-07-15) pins (from its docker/docker-compose.yml at the v3.0.3 tag): postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191… and valkey:9@sha256:4963247afc4cd33c7d3b2d2816b9f7f8eeebab148d29056c2ca4d7cbc966f2d9 (same valkey pin as v3.0.2). The recipe (origin/main, published 1.9.0+v3.0.1) is AHEAD on postgres:14-vectorchord0.4.3-pgvectors0.3.0@sha256:87c050465… (pgvectors 0.2.0→0.3.0, backward- compatible — keep it, do NOT downgrade to immich's 0.2.0). Digest re-verified identical via docker buildx imagetools inspect on cc-ci (2026-07-17). The recipe's valkey pin valkey:9@sha256:3b55fbaa… (origin/main) is a STALE old digest for tag 9; immich v3.0.3 ships 4963247afc4cd…, so the recipe is re-pinned to that (the tested combo) — NOTE the live valkey:9 tag now resolves further to sha256:8e8d64b4… (newer 9.x build, NOT tested with immich v3.0.3), so pin to immich's 4963247afc4cd… for reproducibility, not the live tag digest. Refreshed to 4963247afc4cd… in the 2026-07-17 upgrade (v3.0.1→v3.0.3, extending PR #4).
  • immich-server v3.1.0 (2026-07-29) pins (from its docker/docker-compose.yml at the v3.1.0 tag): valkey:9@sha256:8e8d64b405ce18f41b8e5ee20aa4687a8ed0022d1298f2ce31cdcf3a76e09411 (a NEWER valkey build than v3.0.3's 4963247afc4cd… — this 8e8d64b4… is the same digest the live 9 tag had already moved to at the 2026-07-17 run; immich v3.1.0 now officially ships it, so it IS the immich-tested combo → re-pin the recipe's redis service to 8e8d64b4… for the v3.1.0 upgrade) and postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191… (SAME combo as v3.0.3 — immich did NOT bump vectorchord/pgvectors, so the recipe STAYS AHEAD on pgvectors0.3.0@sha256:87c050465…; do NOT downgrade). Only breaking change in v3.1.0 is chore(mobile): drop support for iOS 14 (mobile client, NOT server-side — no server migration, no DB migration, no operator action for the recipe). Done in the 2026-07-31 upgrade (v3.0.1→v3.1.0, extending PR #4 again).
  • 2026-08-07: upstream main MOVED to v3.1.0 (published 1.10.0+v3.1.0, commit 794560f). The coopcloud maintainer published v3.1.0 independently of PR #4 (PR #4 tip 77d7937 is NOT in upstream main, so the reconcile leaves it open — functionally superseded on the version bump). Upstream main pins: immich-server/ML v3.1.0, postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf633… (immich's OFFICIAL v3.1.0 combo — a DOWNGRADE from the recipe's prior pgvectors0.3.0@87c0…), and valkey:9@sha256:3acc0687f2a2e1091fae6450d7842dd658c941338cf0a873ddd9e14b9e4ea4dd (DIVERGES from immich v3.1.0's official valkey pin 8e8d64b4… — upstream pin hygiene discrepancy, not an upgrade). Immich is now up-to-date (v3.1.0 is latest stable per GitHub releases; no v3.1.x patch / v3.2.x). PR #4 now diverges from upstream main only on database (pgvectors0.3.0 vs 0.2.0) + redis (valkey:9@8e8d64b4 vs @3acc0687) pins — operator decides merge-vs-close.
  • immich-server v3.2.0 (2026-09-10) pins (from its docker/docker-compose.yml at the v3.2.0 tag): valkey:9@sha256:70739f85ad2ee01a726a965584a0f94895f01b0c60b3cc8b0aeef11eaa6888cf (= valkey 9.1.1 per image env; a NEWER build than v3.1.0's 8e8d64b4… = 9.1.0 — but OLDER than the live 9 tag, which by 2026-09-11 moved to c123e371… = 9.1.2; pin immich's tested 70739f85…, NOT the live tag, per the 2026-07-17 precedent) and postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357… (SAME combo as v3.1.0 — DB unchanged). No breaking server-side changes in v3.2.0; example.env byte-identical to v3.1.0; TypeORM migrations auto-run. Operator-info only: the new opt-in cluster-groups feature requires a per-group facial-recognition reset (user-triggered button, not a deploy migration). ghcr pagination gotcha (hit 2026-09-11): ghcr.io/v2/immich-app/postgres/tags/list pages are ~100 tags, NOT purely lexicographic, and the Link: header returns a RELATIVE url (/v2/...) — prefix the host or pagination silently stops at page 1; the pinned pg tag 14-vectorchord0.4.3- pgvectors0.2.0 is on page 2 of 174 (a first-page probe wrongly suggests it's gone). Upstream coopcloud has open renovate PRs #18 (v3.2.0 monorepo bump = server+ML only), #17 (valkey digest → live c123e37 — not immich's tested pin), #16 (postgres → pg16 — unsupported by immich v3.2.0, reject). Done in the 2026-09-11 upgrade (v3.1.0→v3.2.0, extending PR #4 from upstream main 794560f; PR #4's pgvectors0.3.0/valkey-8e8d64b4 divergences superseded — DB realigned to immich's official combo, which upstream main itself chose 2026-08-07).
  • 2026-08-07 INFRA note: cc-ci runner's gitea clone-token is STALE (HTTP 401). !testme build #1210 died at the recipe git clone step (~5s, before any deploy) with could not read Username for 'https://git.autonomic.zone' — the runner's mounted gitea token 13e299f2… is rejected (verified HTTP 401 on the gitea API + git endpoint; .testenv basic creds work). PR #4's tree 77d79379 was GREEN on #1145 (2026-07-31) & #1180 (2026-08-04) — the RED is infra, not the recipe. Fix: rotate the runner's gitea clone-token (swarm secret), then re-!testme. (The 2026-08-04 Drone-direct GITEA_TOKEN-as-build-param workaround is disallowed for normal runs.)
  • Historical (v2.7.5, 2026-04-13): immich-server v2.7.5 pinned postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191…. PR #2 bumped the recipe to pgvectors0.3.0@sha256:87c050465… (same PG14 + VectorChord 0.4.3, newer pgvectors 0.2.0→0.3.0).
  • Concurrent app+database restart needs update_config: failure_action: continue on the app service. When the recipe version label changes (bumping coop-cloud.${STACK_NAME}.version) AND the database image changes in the same deploy, both services update simultaneously. The app container starts and immediately tries TypeORM migrations against a still-restarting database → TypeORM connection fails → app process crashes → task FAILED → Docker Swarm sets UpdateStatus='paused' (default failure_action: pause). Fix: set update_config: failure_action: continue on the app service. With continue, Docker Swarm records the update as completed and Docker's restart_policy retries the app container; the database finishes restarting in ~15-20s and the app connects successfully. This is also in the recipe as of PR #2.
  • VectorChord DB backup/restore needs the search_path sed. A plain pg_dump of the VectorChord/pgvecto.rs DB emits SELECT pg_catalog.set_config('search_path', '', false);. Importing that as-is leaves the vector/vchord type + operator references unresolvable, so the first such statement errors. immich's official restore (docs.immich.app/administration/backup-and-restore) pipes the dump through: sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" before psql … --single-transaction --set ON_ERROR_STOP=on. Omitting that sed (immich PR #1's pg_backup.sh) is why the single-transaction import aborted wholesale and ci_marker was lost on restore — fixed in the upgrade PR's pg_backup.sh.
Reference in New Issue View Git Blame Copy Permalink