Bring the README and client/README in line with the current product and
release pipeline ahead of making the repo public-facing:
- Highlights: replace the retired "Flutter client in flight" bullet with
the native-Android-APK-bundled-in-the-image story.
- Quickstart: document the purpose of each compose volume mount, and fix
the minstrel-data mount (/data -> /app/data) so it matches the image's
MINSTREL_STORAGE_DATA_DIR and generated artefacts actually persist.
- Configuration: tie MINSTREL_STORAGE_DATA_DIR to the /app/data mount.
- Updating: replace the bogus :v1.0.x scheme with the real tag model
(:latest, immutable :vYYYY.MM.DD, :main) and note the bundled APK.
- client/README: rewrite the Production section to match release.yml
(android-release + needs: ordering, non-tag :latest bundle path).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- rename .forgejo/workflows/ to .gitea/workflows/ (git mv preserves
history); Gitea Actions reads either path, but the directory now
matches the active platform
- collapse ANDROID_STORE_PASSWORD + ANDROID_KEY_PASSWORD into a
single ANDROID_KEYSTORE_PASSWORD secret (PKCS12 keystores require
the two passwords to be identical, so the duplication carried no
information); build.gradle.kts still reads two env vars to stay
format-agnostic, both now sourced from the same secret in CI
- ignore android/*.keystore, android/*.keystore.*, android/*.jks,
android/keystore.properties so the regenerated signing material
never reaches a remote on accident
- update prose references from Forgejo to Gitea in CLAUDE.md and
the docs; the historical "migrated from Forgejo" note in CLAUDE.md
is kept intentionally; forgejo/upload-artifact@v3 action refs are
left untouched (canonical artifact action, resolves cleanly under
Gitea Actions)
Operator side: ANDROID_KEY_ALIAS, ANDROID_KEYSTORE_PASSWORD, and
ANDROID_KEYSTORE_B64 secrets registered in Gitea before this lands.
Final phase of the in-app update flow. release.yml on tag pushes
fetches the APK that flutter.yml is attaching to the same release,
drops it into client/ in the build context, and the Dockerfile's
COPY client/ /app/client/ bakes it into the image.
### How it sequences
flutter.yml and release.yml both trigger on tag pushes and run in
parallel on different runners (flutter-ci vs go-ci). flutter.yml
typically finishes APK build + release attachment in 2-5 min.
release.yml polls the release page for up to 15 min for the APK to
appear, then proceeds. If the APK never lands (flutter.yml failure,
network hiccup), release.yml emits a warning and ships the image
without the bundled APK — server returns 404 from /api/client/version,
banner stays hidden, manual download from the release page still
works. Graceful degradation, not a blocker.
### Repo shape
- client/.gitkeep + client/README.md so the directory exists in git
and the COPY in the Dockerfile always finds something to copy
- .gitignore excludes client/minstrel.apk + .version so accidental
commits don't bloat the repo
- Dockerfile: COPY --chown=minstrel:minstrel client/ /app/client/
### Why polling vs cross-workflow trigger
Forgejo Actions' workflow_run support varies by runner version; the
polling approach is universally compatible. If/when we standardize on
a runner that handles workflow_run cleanly, the polling step can
become a `needs:` dependency.
Closes#397.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
bvandeusen