Commit Graph

4 Commits

Author SHA1 Message Date
9697b56404 ci(release): publish the release bundle to Google Play
Adds Play as a third channel alongside the F-Droid repo and the Codeberg
download. It gets its own artifact: bundleRelease produces an AAB from
the same source and signing config as the published APK, which is left
untouched so the F-Droid reproducibility guarantee is unaffected.

The upload runs as a separate trailing job rather than more steps in
'release'. Play is the only channel that can reject a good build for
reasons the pipeline cannot see — listing rules, policy review, a track
needing manual promotion — and that must surface as one red job beside a
release that already shipped, not as a failure of the workflow that
shipped it. It also skips cleanly until PLAY_SERVICE_ACCOUNT_JSON
exists, so the pipeline keeps working during Play Console setup.

fastlane is scoped deliberately to 'supply'. Build and signing stay on
Gradle: interposing fastlane there would add a layer able to inject
flags into the one build a third party verifies byte-for-byte. What
fastlane buys is that fastlane/metadata/android — already the source
F-Droid harvests — is exactly what supply consumes, so 'What's New'
comes from CHANGELOG.md via the existing sync script for both stores.

Listing text is not pushed per release (an accidental overwrite of a
live listing is a policy-review event, not a revert), and images are
skipped because the committed assets satisfy F-Droid but not Play: the
screenshots are 1280x2856 with alpha where Play caps the long edge at 2x
the short edge and wants 24-bit, and no 1024x500 featureGraphic exists.

The job runs without a container image despite fastlane publishing one:
act_runner provides no node inside custom job containers, so checkout
and download-artifact cannot run there.

Uploads default to the internal track — promotion to production stays a
human action, matching the rule that UI releases wait for on-device
review.

Note that Play App Signing means Play installs and F-Droid installs
carry different signatures and cannot update each other; the release key
is registered only as the upload key. Documented in docs/RELEASING.md.
2026-07-29 16:42:00 +02:00
bb7954d026 Remove superpowers planning docs; ignore CLAUDE.md
All checks were successful
Release — F-Droid repo + Gitea release / detect (push) Successful in 6s
Release — F-Droid repo + Gitea release / release (push) Successful in 7m3s
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 17:43:22 +02:00
e5be5f1ae5 security(release): rotate compromised F-Droid repo key; keep key out of served tree
All checks were successful
CI / ci (push) Successful in 5m17s
The F-Droid repo signing key (keystore.p12) and its config.yml — including
the keystore passwords in cleartext — were publicly downloadable at
apps.dev.jeanlucmakiola.de/dev/fdroid/ because the release workflow uploaded
the entire fdroid/ working dir into the web-served path. The webserver has
since been locked down to repo/ only; this rotates the now-compromised key
and removes the root cause.

- release.yaml: restore the repo key + config from new CI secrets
  (FDROID_KEYSTORE_BASE64, FDROID_CONFIG_BASE64) instead of the box; upload
  ONLY repo/ so the key never re-enters the served tree.
- release.yaml: fail loudly when the repo key secrets are unset, replacing
  `fdroid update --create-key`, which silently minted a NEW repo key on a
  wiped server and would have broken every user's pinned fingerprint.
- README: publish the new repo fingerprint (C2C0…3425). Existing users must
  remove and re-add the repo.
- .gitignore: ignore *.p12 and the whole /fdroid/ working dir.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-14 12:01:00 +02:00
Jean-Luc Makiola
a8ba6e32e2 chore: add repo meta files (LICENSE, README, CHANGELOG, gitignore)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-06-08 14:54:40 +02:00