81 lines
7.2 KiB
Markdown
81 lines
7.2 KiB
Markdown
# 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.
|
|
- **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`.
|