ci: release notarized Meetingnotes updates through Gitea

README.md

@@ -46,7 +46,7 @@ Later:
 ## Releasing a New Version
 
 Production releases are Developer ID signed, notarized by Apple, published to
-GitHub Releases, and signed for Sparkle auto-updates.
+[Gitea Releases](https://git.jamesbone.net/coder/meetingnotes/releases), and signed for Sparkle auto-updates.
 
 ### Release Process
 
@@ -68,12 +68,12 @@ GitHub Releases, and signed for Sparkle auto-updates.
 
 2. Commit and push the version change to `main`.
 
-3. Run the `Release` workflow from GitHub Actions and enter the version without
+3. Run the `Release` workflow from Gitea Actions on `main` and enter the version without
    the `v` prefix. The workflow signs and notarizes the app, generates the
    signed appcast, creates the version tag, and publishes both release assets.
 
 The app checks
-`https://github.com/superdooper86/meetingnotes/releases/latest/download/appcast.xml`
+`https://git.jamesbone.net/coder/meetingnotes/releases/download/latest/appcast.xml`
 and installs later releases automatically through Sparkle.
 
 ### Recovering Meetings
@@ -82,3 +82,18 @@ The first Developer ID signed build may not automatically inherit data from an
 older ad-hoc signed build. In Settings, use **Import Meetings...** and select the
 old `Meetings` folder. After this one-time transition, the stable signing
 identity keeps the same sandbox container across updates.
+
+### Build runner and GitHub transition
+
+`.gitea/workflows/build.yml` builds universal macOS artifacts for pushes and pull
+requests to `main`. The repository-scoped `mac-mini-meetingnotes` runner uses the
+`macos-arm64` label. Smoke tests use a separate CI bundle identifier and temporary
+launch preferences. Release jobs import the original Developer ID certificate
+into a temporary keychain and keep the original Sparkle signing key in Gitea
+Actions secrets. They never publish from a development branch.
+
+Version 1.1.33 moves the embedded update feed to Gitea. After its notarized archive
+is verified, replace the `appcast.xml` asset on the last GitHub release with the
+new appcast. Existing installations discover the Gitea download through that old
+GitHub feed; after installing it, they check Gitea directly. Keep the old GitHub
+repository and its release appcast available for installations that update later.