ci: build the production image in CI

Dokploy built from source on the host, so every deploy paid a full cold
cargo build and the layer cache died with the builder. CI now builds and
pushes to the Gitea registry, and the deploy is a pull.

The Gitea push webhook fires before Actions starts, so autoDeploy on the
Dokploy application is off and this job triggers the deploy itself.

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

.gitea/workflows/ci.yml

@@ -4,6 +4,7 @@ on:
   push:
     branches:
       - main
+      - docker          # TEMP: probe the image job before merge
   pull_request:
 
 env:
@@ -119,3 +120,69 @@ jobs:
       - name: design tokens
         if: steps.probe.outputs.present == 'true'
         run: pnpm -C web run check-tokens
+
+  # Build the production image here rather than on the Dokploy host: the gate
+  # above has to pass first, the layer cache lives in the registry instead of
+  # being thrown away every deploy, and Dokploy's job shrinks to a pull.
+  #
+  # This job is also the deploy trigger. The Gitea push webhook fires the
+  # instant the commit lands, long before the image exists, so autoDeploy on
+  # the Dokploy application must stay off — the deploy is the last step here.
+  image:
+    needs: [rust, web]
+    if: github.event_name == 'push' && (github.ref == 'refs/heads/main' || github.ref == 'refs/heads/docker')
+    runs-on: ubuntu-latest
+    env:
+      IMAGE: git.naps.pt/yolo/arr
+      DOKPLOY_APP_ID: uEaWG5JDpVIrJloG5rMAP
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Docker CLI and buildx
+        run: |
+          apt-get update
+          apt-get install -y --no-install-recommends ca-certificates curl gnupg
+          . /etc/os-release
+          install -m 0755 -d /etc/apt/keyrings
+          curl -fsSL "https://download.docker.com/linux/$ID/gpg" \
+            -o /etc/apt/keyrings/docker.asc
+          chmod a+r /etc/apt/keyrings/docker.asc
+          echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc]" \
+               "https://download.docker.com/linux/$ID $VERSION_CODENAME stable" \
+            > /etc/apt/sources.list.d/docker.list
+          apt-get update
+          apt-get install -y --no-install-recommends docker-ce-cli docker-buildx-plugin
+          docker version
+
+      - name: Registry login
+        run: |
+          printf '%s' "${{ secrets.REGISTRY_TOKEN }}" \
+            | docker login git.naps.pt -u "${{ secrets.REGISTRY_USER }}" --password-stdin
+
+      - name: Buildx builder
+        # The default docker driver cannot export a cache. docker-container can.
+        run: docker buildx create --name arr --driver docker-container --use
+
+      - name: Build and push
+        run: |
+          docker buildx build \
+            --tag "$IMAGE:sha-$GITHUB_SHA" \
+            --tag "$IMAGE:main" \
+            --cache-from "type=registry,ref=$IMAGE:buildcache" \
+            --cache-to "type=registry,ref=$IMAGE:buildcache,mode=max" \
+            --push .
+
+#      - name: Deploy
+#        # Pinned to the commit sha, not :main — swarm does not reliably re-pull
+#        # an unchanged tag name, and an older sha is the rollback.
+#        run: |
+#          # The package is public (org yolo is public), so Dokploy pulls with
+#          # no credentials and the registry fields stay null.
+#          curl -fsS -X POST https://dokploy.n62.casa/api/application.update \
+#            -H "x-api-key: ${{ secrets.DOKPLOY_API_KEY }}" \
+#            -H 'content-type: application/json' \
+#            -d "{\"applicationId\":\"$DOKPLOY_APP_ID\",\"dockerImage\":\"$IMAGE:sha-$GITHUB_SHA\"}"
+#          curl -fsS -X POST https://dokploy.n62.casa/api/application.deploy \
+#            -H "x-api-key: ${{ secrets.DOKPLOY_API_KEY }}" \
+#            -H 'content-type: application/json' \
+#            -d "{\"applicationId\":\"$DOKPLOY_APP_ID\",\"title\":\"ci ${GITHUB_SHA:0:8}\"}"

Dockerfile

@@ -8,17 +8,35 @@ RUN pnpm -C web install --frozen-lockfile --config.dangerouslyAllowAllBuilds=tru
 COPY web ./web
 RUN pnpm -C web build
 
-FROM rust:1-bookworm AS build
+# Every translation backend is a default-off cargo feature (DESIGN.md §15), so
+# a build without these ships an image that cannot translate at all. All four
+# go in: which one is in use is a database setting, and the point of the
+# feature switches is the build, not the deployment.
+#
+# The dependency build and the workspace build are split with cargo-chef so a
+# source-only change reuses the dependency layer. The two `cargo` invocations
+# must carry identical flags or the cook output is not reusable.
+FROM lukemathwalker/cargo-chef:latest-rust-1-bookworm AS chef
 WORKDIR /src
+ENV ARR_FEATURES=translate-openai,translate-deepl,translate-google,translate-command
+
+FROM chef AS planner
+COPY . .
+RUN cargo chef prepare --recipe-path recipe.json
+
+FROM chef AS build
+COPY --from=planner /src/recipe.json recipe.json
+# cargo-chef's skeleton keeps build scripts, and arr-daemon's panics in release
+# when it can find no SPA bundle. A stub satisfies it; the real bundle arrives
+# below and the changed ARR_WEB_DIST reruns only that one build script.
+RUN mkdir -p /stub/dist && printf '<!doctype html>stub\n' > /stub/dist/index.html
+ENV ARR_WEB_DIST=/stub/dist
+RUN cargo chef cook --release -p arr-daemon --features "$ARR_FEATURES" \
+    --recipe-path recipe.json
 COPY . .
 COPY --from=web /src/web/dist ./web/dist
 ENV ARR_WEB_DIST=/src/web/dist
-# Every translation backend is a default-off cargo feature (DESIGN.md §15),
-# so a build without this line ships an image that cannot translate at all.
-# All four go in: which one is in use is a database setting, and the point of
-# the feature switches is the build, not the deployment.
-RUN cargo build --release -p arr-daemon \
-    --features translate-openai,translate-deepl,translate-google,translate-command
+RUN cargo build --release -p arr-daemon --features "$ARR_FEATURES"
 
 # §15 runs `alass` over every fetched and every translated subtitle, and it is
 # not in Debian — a release binary is the only way in. Its own stage so the