CI: build and publish every package from Woodpecker

Pushes to main run the tests. The Deploy button publishes the Windows, RPM,
deb and F-Droid packages to the same NAS directories a dev machine uses, with
the same keys, then runs update-repo.sh, so public URLs don't change.

Builds run on Debian 12, in an image defined in ci/builder, so the Linux
packages now need glibc 2.36 instead of Fedora 44's 2.43.

README.md

@@ -136,8 +136,9 @@ From then on, `sudo dnf upgrade` picks up new releases.
   trust a new key before it takes another update.
 - Versions work as on Android: `0.1.<commits on HEAD>`, see
   [Distributing to phones](#distributing-to-phones-f-droid).
-- The RPM is built against this machine's libraries, so it installs on this
-  Fedora release and newer.
+- The RPM is built against the build machine's libraries, so it needs at least
+  that machine's glibc. Built by [CI](#publishing-from-ci), that's glibc 2.36;
+  built on Fedora 44, it's Fedora 44 and newer.
 
 ### Distributing to Debian/Ubuntu (apt repo)
 
@@ -186,9 +187,10 @@ From then on, `sudo apt upgrade` picks up new releases.
 - Versions are the same as the RPM's. A build published with `--allow-dirty`
   gets a `~dirty` suffix, which apt sorts below the clean build of the same
   version.
-- The `.deb` is built against this machine's libraries, so it needs a distro
-  with at least this Fedora's glibc (2.43 on Fedora 44). Older Debian and
-  Ubuntu releases can't install it.
+- The `.deb` is built against the build machine's libraries, so it needs a
+  distro with at least that machine's glibc. Built by
+  [CI](#publishing-from-ci), that's glibc 2.36: Debian 12 and Ubuntu 24.04 or
+  newer. Built on Fedora 44, it's glibc 2.43, which they can't install.
 
 ### Distributing to Windows
 
@@ -229,6 +231,37 @@ installed app in place.
 - Versions work as on Android: `0.1.<commits on HEAD>`, see
   [Distributing to phones](#distributing-to-phones-f-droid).
 
+### Publishing from CI
+
+Woodpecker can do all of the above, through the same scripts. Every push to
+`main` runs the tests (`.woodpecker/check.yaml`). To publish, open a pipeline,
+click **Deploy**, and set the deploy target:
+
+| Target | What it does |
+|---|---|
+| `all` | Publishes every package below |
+| `windows`, `rpm`, `deb`, `fdroid` | Publishes just that package |
+| `builder` | Rebuilds the image the pipelines run in, from `ci/builder` |
+
+`all` doesn't include `builder`. Rebuild the image after changing its
+Dockerfile, and before the first run of anything else.
+
+- **It publishes to the same place you do.** The pipeline mounts the release
+  directory and its keys from the NAS at `/nfs/hal9000/mtgc`, then runs that
+  directory's `update-repo.sh` to copy the public files out, so CI and a dev
+  machine can each publish the next release. `scripts/ci-publish.sh` sets up
+  what a fresh container lacks and runs the publish script.
+- A target that fails doesn't stop the others, but the pipeline ends up red.
+  Restarting it is safe: targets that already have this version are skipped.
+- The volumes are defined in the platform repo (`src/apps/woodpecker`). This
+  repo must be marked **Trusted → Volumes** in Woodpecker to mount them, and
+  needs the `registry_username` and `registry_password` secrets to push the
+  image.
+- `sdk_path` in the F-Droid repo's `config.yml` must be `$ANDROID_HOME`, as the
+  SDK is somewhere else on each machine.
+- Builds are cached on the `mtgc-ci-cache` volume. It's safe to delete anything
+  on it; the next build just takes longer.
+
 ## Using it
 
 - **Add Cards** — type a name (typos OK); ↑/↓ then Enter adds a copy.