ci: a commit that passed the checks isn't checked again

A fast-forward merge brings the commit a branch's push checked to main
unchanged, and CI ran every check a second time before deploying it. The
check job now marks every commit that passed in the runner's home
(checked/, kept 90 days), and a commit marked already skips straight to
its deploy; the sandbox check still runs every time. Only pushes run CI,
so only those who may push can leave a mark.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>

.forgejo/workflows/ci.yaml

@@ -1,6 +1,7 @@
 # CI: every push runs the checks of the pre-push hook (tool/check.sh); a push to main is
 # then deployed to learn.halkyon.eu (deploy/redeploy.sh). Both jobs run on the runner on
-# sahaquiel, directly on the host as an unprivileged user (deploy/runner/).
+# sahaquiel, directly on the host as an unprivileged user (deploy/runner/). A commit
+# that passed the checks before isn't checked again (see "Checked before?").
 #
 # Pushes only, no pull requests: a pull request from a fork would run its own code on
 # the production server's runner.
@@ -44,7 +45,19 @@ jobs:
           fi
           echo "This job can neither see nor reach production."
 
+      # A commit that passed this job before isn't checked again: a fast-forward merge
+      # brings the commit a branch's push checked to main unchanged, and only its deploy
+      # is new. The marks live in the runner's home; only pushes run this workflow, so
+      # only those who may push can leave one. Every later step of this job asks.
+      - name: Checked before?
+        run: |
+          if [ -e "$HOME/checked/${{ github.sha }}" ]; then
+            echo "${{ github.sha }} passed these checks before; they aren't run again."
+            echo 'CHECKED_BEFORE=true' >> "$FORGEJO_ENV"
+          fi
+
       - name: Check out
+        if: env.CHECKED_BEFORE != 'true'
         env:
           TOKEN: ${{ github.token }}
         run: |
@@ -58,6 +71,7 @@ jobs:
           git clean -q -ffdx
 
       - name: Flutter
+        if: env.CHECKED_BEFORE != 'true'
         run: |
           sdk="$HOME/sdk/flutter-$FLUTTER_VERSION"
           if [ ! -x "$sdk/bin/flutter" ]; then
@@ -81,12 +95,14 @@ jobs:
       # second goes through. Drop it once the Dart of FLUTTER_VERSION has pub's fix
       # (ebba0dc, pull request 4914).
       - name: Dependencies
+        if: env.CHECKED_BEFORE != 'true'
         run: flutter pub get --enforce-lockfile || flutter pub get --enforce-lockfile
 
       # The generated code (the server's lib/src/generated, the client package) is
       # committed, so it has to be exactly what the generator makes of the models and
       # endpoints: a model changed without regenerating fails here.
       - name: Generated code
+        if: env.CHECKED_BEFORE != 'true'
         run: |
           bin="${XDG_STATE_HOME:-$HOME/.local/state}/Dart/install/bin"
           if ! "$bin/serverpod" --no-analytics version 2>/dev/null | grep -qx "Serverpod version: $SERVERPOD_VERSION"; then
@@ -104,6 +120,7 @@ jobs:
       # Throwaway and new for every job: they only guard the test database the job creates
       # in its own checkout.
       - name: Test passwords
+        if: env.CHECKED_BEFORE != 'true'
         run: |
           for name in SERVERPOD_DATABASE_PASSWORD \
             SERVERPOD_PASSWORD_serverSideSessionKeyHashPepper \
@@ -112,8 +129,17 @@ jobs:
           done
 
       - name: Checks
+        if: env.CHECKED_BEFORE != 'true'
         run: tool/check.sh
 
+      # Reached only when every step above passed. Marks older than 90 days go.
+      - name: Remember the commit
+        if: env.CHECKED_BEFORE != 'true'
+        run: |
+          mkdir -p "$HOME/checked"
+          touch "$HOME/checked/${{ github.sha }}"
+          find "$HOME/checked" -type f -mtime +90 -delete
+
   deploy:
     needs: check
     if: github.ref == 'refs/heads/main'

AGENTS.md

@@ -117,7 +117,7 @@ A spaced-repetition learning app: studysets of flashcards, reviewed on an FSRS s
 
 ## CI and deploys
 
-- **CI** (`.forgejo/workflows/ci.yaml`) runs `tool/check.sh` on every push, on the Forgejo runner on sahaquiel (`deploy/runner/`). Jobs run directly on the host as the unprivileged user `runner`, never in containers: Docker access would be root on the production server. The runner's systemd unit keeps jobs away from production (no `/home`, no Docker socket, Docker's container networks unreachable, memory and CPU capped); keep it that way when changing it. `runner` has user ID 61000 and must never share one with a container's processes (PostgreSQL and the server run as 999, not remapped): the same user ID can read their environment and files. The job's first step (*Sandbox*) fails if any of this leaks. Flutter is pinned in the workflow (`FLUTTER_VERSION`): move it together with the local one. The server tests there get throwaway passwords from the environment (`SERVERPOD_…`, new for every job), since `passwords.yaml` is never committed; without them they exit with code 1 and no message (Serverpod's own template does the same). CI also runs `serverpod generate` and fails if the committed generated code differs from its output. CI runs on pushes only: a pull request from a fork would run its code on the production server.
+- **CI** (`.forgejo/workflows/ci.yaml`) runs `tool/check.sh` on every push, on the Forgejo runner on sahaquiel (`deploy/runner/`), except for a commit that passed before: the job marks passed commits in the runner's home (`checked/`, kept 90 days), so a branch's commit fast-forwarded into `main` goes straight to its deploy. Jobs run directly on the host as the unprivileged user `runner`, never in containers: Docker access would be root on the production server. The runner's systemd unit keeps jobs away from production (no `/home`, no Docker socket, Docker's container networks unreachable, memory and CPU capped); keep it that way when changing it. `runner` has user ID 61000 and must never share one with a container's processes (PostgreSQL and the server run as 999, not remapped): the same user ID can read their environment and files. The job's first step (*Sandbox*) fails if any of this leaks. Flutter is pinned in the workflow (`FLUTTER_VERSION`): move it together with the local one. The server tests there get throwaway passwords from the environment (`SERVERPOD_…`, new for every job), since `passwords.yaml` is never committed; without them they exit with code 1 and no message (Serverpod's own template does the same). CI also runs `serverpod generate` and fails if the committed generated code differs from its output. CI runs on pushes only: a pull request from a fork would run its code on the production server.
 - **A green `main` deploys learn.halkyon.eu** through `deploy/redeploy.sh`, the only command the runner's key may run as `deploy` (pinned in `authorized_keys`, from sahaquiel itself only). It deploys the commit CI checked while it is still the tip, as a fast-forward, only if every new commit is signed by a key in `deploy/allowed-signers` (the deployed copy decides), after dumping the database (the last 3 dumps stay in `~deploy/backups`: the way back from a deploy, not backups), applies the migrations in a run of their own before switching (`--role=maintenance --apply-migrations`: a failing migration stops the deploy while the old server keeps serving, so migrations must keep the old server working until the switch), and fails unless the new server answers. A failed deploy leaves the checkout at the deployed commit; run the workflow again to retry. By hand: `ssh sahaquiel-deploy halkyon-learn/deploy/redeploy.sh <commit>`. Never `docker compose down -v` there.
 - **Backups** (`deploy/backups.md`): every hour, `deploy/backup.sh` (a systemd timer, as `deploy`) dumps the database, which holds people's files too, and restic stores it in a Hetzner Storage Box (24 hourly, 7 daily, 4 weekly, 3 monthly); the box's own snapshots protect it from a taken-over server. A restore takes the instance back up to an hour, and people who started since lose what their device held: their app no longer finds its session, starts a new anonymous account and deletes the old folder. So a change that makes devices lose their session, or keeps deleted people's data longer, changes what a restore costs; say so in `deploy/backups.md`.
 - **Releases** are the project's, not an instance's: the release, the Snap Store listing and the website point to learn.halkyon.app; the builds connect to learn.halkyon.eu, the project's instance, until the app lets people choose one. They come from a developer's laptop, never from CI: `tool/release.sh` on `main` as pushed and green in CI. Versions follow semantic versioning, worked out from the commits since the last release (`feat` raises the minor number, `fix`/`perf` the patch number, breaking ones the major from 1.0 on; other types release nothing), so **commit messages keep their type prefix**. It writes the version and a raised build number into the app's pubspec in a signed release commit (`chore(release): vX.Y.Z`) with a signed tag (a key in `deploy/allowed-signers`), builds one universal APK from a checkout of the tag, signed with the app's key, and the snap (`snap/snapcraft.yaml`, the committed HEAD, built in LXD), both with `SERVER_URL=https://learn.halkyon.eu/`; signs `SHA256SUMS` with GPG; pushes only once both builds passed their checks; and publishes on code.halkyon.app through Forgejo's API and in the F-Droid repository. The Snap Store upload is off until `snap_store_channel` in the script names a channel. A run that stopped after its release commit and tag carries on with them. The key's password and the Forgejo token are asked for at each run and never stored. The app's key is a PKCS #12 keystore outside the repository (also in the maintainer's password manager); there is no Google Play, so it is the app's identity: lost, installed apps can't be updated. Its certificate's SHA-256 is in `tool/release/android-certificate.sha256`, and the script releases no APK signed otherwise; other release builds fall back to the debug key (`android/app/build.gradle.kts`), so `flutter run --release` works anywhere. The APK also goes into the project's own F-Droid repository, https://halkyon.app/fdroid/repo, through `tool/fdroid_repo.sh` (fdroidserver v2.4.5): its settings and the app's listing are in `tool/release/fdroid/` (the anti-features TetheredNet and NonFreeNet declared with their reasons and F-Droid's own icons); its index is signed with a key of its own (a PKCS #12 keystore beside the app's, password asked for, certificate pinned in `tool/release/fdroid-index-certificate.sha256`, since a new key makes the F-Droid app refuse the repository); and it is uploaded to ramiel as the user `fdroid`, whose key can only write into the folder Caddy serves (rrsync), the APKs first and the indexes last.