Use a minimal registry PAT and the job token for releases

Gitea's container registry rejects the automatic job token
(go-gitea/gitea#23642 is still open), so the image push keeps a PAT with
only the write:package scope; a preflight step fails clearly when the
REGISTRY_USER/REGISTRY_TOKEN secrets are missing. Release creation needs
no PAT: the desktop job asks for contents: write on the job token.

.gitea/workflows/cd.yml

@@ -0,0 +1,163 @@
+# J621 CD — manual release workflow (Actions tab -> "Run workflow").
+#
+# One dispatch does everything:
+#   * builds and pushes the backend + frontend images (multi-arch, :latest
+#     and :<short-sha>, GIT_HASH baked in for the version pill),
+#   * builds the desktop packages and attaches them (plus the update
+#     metadata) to the Gitea release tagged `desktop-v<package.json version>`.
+#
+# The live update feed (deploy/data/desktop, served by the frontend nginx at
+# /desktop/) is not touched here: it is runtime state on the deploy host and
+# is still published with `deploy/push_desktop.sh --no-build` from a machine
+# that can reach it.
+#
+# Registry login uses a repo PAT with the minimal write:package scope (the
+# Gitea registry rejects the automatic job token, go-gitea/gitea#23642);
+# release creation uses the automatic job token. Jobs run on the user-scoped
+# nitro-ci runner (ubuntu-latest).
+
+name: CD
+
+on:
+  workflow_dispatch:
+    inputs:
+      platforms:
+        description: Image platforms (comma separated)
+        required: false
+        default: linux/amd64,linux/arm64
+      windows:
+        description: Also cross-build the Windows installer (needs wine, slow)
+        required: false
+        default: "false"
+
+concurrency:
+  group: cd
+  cancel-in-progress: false
+
+jobs:
+  images:
+    name: Build & push images
+    runs-on: ubuntu-latest
+    # The Gitea container registry does not accept the automatic job token
+    # (go-gitea/gitea#23642 is still open), so the push uses a repo PAT with
+    # the minimal write:package scope. Releases use the job token instead.
+    permissions:
+      contents: read
+    env:
+      REGISTRY_USER: ${{ secrets.REGISTRY_USER }}
+      REGISTRY_TOKEN: ${{ secrets.REGISTRY_TOKEN }}
+      PLATFORMS: ${{ inputs.platforms || 'linux/amd64,linux/arm64' }}
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Check the registry credentials
+        run: |
+          if [ -z "$REGISTRY_USER" ] || [ -z "$REGISTRY_TOKEN" ]; then
+            echo "Set the REGISTRY_USER and REGISTRY_TOKEN repo secrets" >&2
+            echo "(a PAT with the write:package scope)." >&2
+            exit 1
+          fi
+
+      - name: Register binfmt (multi-arch builds)
+        run: docker run --privileged --rm tonistiigi/binfmt --install all
+
+      - name: Build & push both images
+        run: |
+          set -euo pipefail
+          SHA="$(git rev-parse --short HEAD)"
+          echo "Publishing $SHA for $PLATFORMS"
+          PLATFORMS="$PLATFORMS" ./deploy/push_frontend.sh "$SHA"
+          PLATFORMS="$PLATFORMS" ./deploy/push_backend.sh "$SHA"
+
+  desktop:
+    name: Desktop release
+    runs-on: ubuntu-latest
+    # Creating the release and uploading its assets uses the automatic job
+    # token, so it needs write access to the repository's releases.
+    permissions:
+      contents: write
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: "22"
+
+      - name: Install packaging tools
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y --no-install-recommends fakeroot libarchive-tools
+          if [ "${{ inputs.windows }}" = "true" ]; then
+            sudo apt-get install -y --no-install-recommends wine
+          fi
+
+      - name: Install frontend + desktop dependencies
+        run: |
+          npm --prefix frontend ci --no-audit --no-fund
+          npm --prefix desktop ci --no-audit --no-fund
+
+      - name: Build desktop packages
+        run: |
+          if [ "${{ inputs.windows }}" = "true" ]; then
+            ./deploy/build_desktop.sh --all
+          else
+            ./deploy/build_desktop.sh --linux
+          fi
+
+      - name: Add the Gitea release
+        env:
+          GITEA_TOKEN: ${{ secrets.GITEA_TOKEN || secrets.GITHUB_TOKEN }}
+        run: |
+          set -euo pipefail
+          VERSION="$(node -p "require('./desktop/package.json').version")"
+          TAG="desktop-v$VERSION"
+          API="${{ github.server_url }}/api/v1/repos/${{ github.repository }}"
+          AUTH="Authorization: token $GITEA_TOKEN"
+
+          NOTES="$(printf 'J621 desktop %s\n\n' "$VERSION"
+            cd desktop/release
+            sha256sum ./*.deb ./*.pkg.tar.zst ./*.exe 2>/dev/null || true)"
+
+          RELEASE_ID="$(curl -sf -H "$AUTH" "$API/releases/tags/$TAG" \
+            | python3 -c 'import json,sys; print(json.load(sys.stdin).get("id",""))' \
+            2>/dev/null || true)"
+          if [ -z "$RELEASE_ID" ]; then
+            echo "Creating release $TAG"
+            PAYLOAD="$(python3 - "$TAG" "${{ github.sha }}" "$NOTES" <<'PY'
+          import json, sys
+          print(json.dumps({
+              "tag_name": sys.argv[1],
+              "name": sys.argv[1],
+              "body": sys.argv[3],
+              "target_commitish": sys.argv[2],
+          }))
+          PY
+          )"
+            RELEASE_ID="$(curl -sf -X POST -H "$AUTH" \
+              -H "Content-Type: application/json" -d "$PAYLOAD" "$API/releases" \
+              | python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])')"
+          else
+            echo "Release $TAG already exists (id $RELEASE_ID); attaching missing files."
+          fi
+
+          EXISTING="$(curl -sf -H "$AUTH" "$API/releases/$RELEASE_ID/assets" \
+            | python3 -c 'import json,sys; print("\n".join(a["name"] for a in json.load(sys.stdin)))' \
+            || true)"
+          for FILE in desktop/release/*"$VERSION"*.deb \
+                      desktop/release/*"$VERSION"*.pkg.tar.zst \
+                      desktop/release/latest-linux.yml \
+                      desktop/release/latest.yml \
+                      desktop/release/*"$VERSION"*.exe \
+                      desktop/release/*"$VERSION"*.exe.blockmap; do
+            [ -e "$FILE" ] || continue
+            NAME="$(basename "$FILE")"
+            case "$EXISTING" in
+              *"$NAME"*) echo "    already attached: $NAME"; continue ;;
+            esac
+            echo "    attaching $NAME"
+            curl -sf -X POST -H "$AUTH" -H "Content-Type: application/octet-stream" \
+              --data-binary @"$FILE" "$API/releases/$RELEASE_ID/assets?name=$NAME" >/dev/null
+          done
+          echo "Release: ${{ github.server_url }}/${{ github.repository }}/releases/tag/$TAG"

.gitea/workflows/ci.yml

@@ -6,6 +6,11 @@
 
 name: CI
 
+# Tests and builds only need to read the repository; the automatic job token
+# stays read-only.
+permissions:
+  contents: read
+
 on:
   push:
     branches: ["**"]
@@ -30,24 +35,25 @@ jobs:
           MARIADB_USER: j621
           MARIADB_PASSWORD: j621
         options: >-
-          --health-cmd "healthcheck.sh --connect --innodb_initialized"
+          --health-cmd="healthcheck.sh --connect --innodb_initialized"
-          --health-interval 5s
+          --health-interval=5s
-          --health-timeout 5s
+          --health-timeout=5s
-          --health-retries 20
+          --health-retries=12
       redis:
         image: redis:7-alpine
         options: >-
-          --health-cmd "redis-cli ping"
+          --health-cmd="redis-cli ping"
-          --health-interval 5s
+          --health-interval=5s
-          --health-timeout 5s
+          --health-timeout=5s
-          --health-retries 20
+          --health-retries=12
     env:
+      # Connect as root so Django can create the test database itself;
+      # everything else mirrors the development defaults.
       DB_HOST: mariadb
       DB_PORT: "3306"
       DB_NAME: j621
-      DB_USER: j621
+      DB_USER: root
-      DB_PASSWORD: j621
+      DB_PASSWORD: root
-      DB_ROOT_PASSWORD: root
       REDIS_URL: redis://redis:6379/1
     steps:
       - uses: actions/checkout@v4
@@ -55,27 +61,10 @@ jobs:
       - uses: actions/setup-python@v5
         with:
           python-version: "3.14"
-          cache: pip
-          cache-dependency-path: backend/requirements.txt
 
       - name: Install backend dependencies
         run: pip install -r backend/requirements.txt
 
-      - name: Install a MariaDB client
-        run: |
-          sudo apt-get update
-          sudo apt-get install -y --no-install-recommends default-mysql-client
-
-      - name: Grant the test database rights
-        run: |
-          for i in $(seq 1 30); do
-            mysql -h "$DB_HOST" -P "$DB_PORT" -u root -p"$DB_ROOT_PASSWORD" \
-              -e "SELECT 1" >/dev/null 2>&1 && break
-            sleep 2
-          done
-          mysql -h "$DB_HOST" -P "$DB_PORT" -u root -p"$DB_ROOT_PASSWORD" \
-            -e "GRANT ALL ON \`test_j621\`.* TO 'j621'@'%'; FLUSH PRIVILEGES;"
-
       - name: Django system checks
         working-directory: backend
         run: python manage.py check
@@ -98,8 +87,6 @@ jobs:
       - uses: actions/setup-node@v4
         with:
           node-version: "22"
-          cache: npm
-          cache-dependency-path: frontend/package-lock.json
 
       - name: Install frontend dependencies
         working-directory: frontend

.gitea/workflows/publish.yml

@@ -1,51 +0,0 @@
-# J621 image publishing — manual workflow.
-#
-# Builds the backend (gunicorn + whitenoise, ffmpeg) and frontend (static
-# nginx) images for linux/amd64 + linux/arm64 and pushes them to the Gitea
-# registry as :latest and :<short-sha>, with the commit baked in as GIT_HASH.
-#
-# Run it from the Actions tab ("Run workflow"), or:
-#   curl -X POST .../api/v1/repos/JakeBreath/J621/actions/workflows/publish.yml/dispatches \
-#        -d '{"ref":"main"}'
-#
-# Registry login uses the automatic GITHUB_TOKEN (the repo needs package write
-# access for the actor); no extra secrets are required.
-
-name: Publish images
-
-on:
-  workflow_dispatch:
-    inputs:
-      platforms:
-        description: Build platforms (comma separated)
-        required: false
-        default: linux/amd64,linux/arm64
-
-concurrency:
-  group: publish
-  cancel-in-progress: false
-
-jobs:
-  publish:
-    name: Build & push images
-    runs-on: ubuntu-latest
-    env:
-      REGISTRY_USER: ${{ github.actor }}
-      REGISTRY_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      PLATFORMS: ${{ inputs.platforms || 'linux/amd64,linux/arm64' }}
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: Register binfmt (multi-arch builds)
-        run: docker run --privileged --rm tonistiigi/binfmt --install all
-
-      - name: Build & push both images
-        run: |
-          set -euo pipefail
-          SHA="$(git rev-parse --short HEAD)"
-          echo "Publishing $SHA for $PLATFORMS"
-          # Both scripts honour REGISTRY_USER/REGISTRY_TOKEN (see deploy/push_*.sh).
-          PLATFORMS="$PLATFORMS" ./deploy/push_frontend.sh "$SHA"
-          PLATFORMS="$PLATFORMS" ./deploy/push_backend.sh "$SHA"

AGENTS.md

@@ -49,6 +49,16 @@ Project constraints (do not regress):
 - Periodic commands (follow syncs, similarity cleanup, guest blacklist
   refresh) run in the composes' `scheduler` service — the backend image with
   the j621-scheduler entrypoint, intervals via J621_*_EVERY. No host cron.
+- CI/CD lives in .gitea/workflows: ci.yml runs on every push/PR (Django checks
+  + the full backend suite against MariaDB/Redis service containers, frontend
+  lint/type-check/build); cd.yml is manual and builds/pushes both images
+  multi-arch plus the desktop packages (attached to the Gitea release
+  `desktop-v<version>`). Jobs run on the user-scoped runners: `ubuntu-latest`
+  on nitro-ci, `desktop` on msi-mortar-ci. Do not add actions/cache
+  (`cache: pip`/`npm`) to these workflows: Gitea's cache service hangs the job
+  on restore/save. The live desktop update feed (deploy/data/desktop) is still
+  published with `deploy/push_desktop.sh --no-build` from a machine with SSH
+  to the deploy host — CI has no key for that.
 - Security/permission tests live in backend/apps/core/tests and need a
   one-time grant: GRANT ALL ON `test_j621`.* TO 'j621'@'%';
 
@@ -85,7 +95,12 @@ Security hardening (do not weaken):
   SECRET_KEY (apps/accounts/crypto.py); rotating SECRET_KEY invalidates them
   (and all signed media URLs), so users must re-enter the key.
 - API throttles live in REST_FRAMEWORK (env-overridable): anon 120/min,
-  user 600/min, login 5/min, register 20/hour, e621_proxy 60/hour.
+  user 600/min, login 5/min, register 20/hour, e621_proxy 60/hour. Signed
+  media URLs (raw/thumbnail/staged-file/similarity-file actions) are exempt
+  on purpose: <img>/<video> tags fetch them without an Authorization header,
+  so a gallery would otherwise drain the anonymous bucket and get 429 JSON
+  instead of images. THROTTLE_ENABLED=false removes the anon+user limits for
+  private/tailnet deployments (the login/register/proxy guards stay).
 - Only admins (superusers) may grant/revoke the staff role or delete
   staff/admin accounts; staff manage regular/uploader accounts only.
 - Storage, duplicates, delete, temp-clear, uploads and downloads require

deploy/README.md

@@ -164,6 +164,16 @@ does not. The desktop app's "Check for updates…" menu item reads
 `latest-linux.yml` / `latest.yml` from there (see `desktop/README.md`).
 Backend-only composes have no frontend, so no feed.
 
+The manual **CD** workflow (Actions tab) builds the desktop packages on the
+runner and attaches them plus the update metadata to the Gitea release
+`desktop-v<version>`; it does not touch the live feed, because that is
+runtime state on the deploy host and CI has no SSH key for it. After a CD run,
+publish the feed from a machine that can reach the deploy checkout:
+
+```bash
+./push_desktop.sh --no-build --local   # or without --local to also copy it
+```
+
 ## Scheduled jobs
 
 Compose files with a backend also run a **`scheduler`** service — the same