4 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	5fb9c1ff3b	ci: publish a rolling latest APK on every push to master ... The test-APK workflow was dispatch-only, so merging to master produced no APK at all -- there was nothing to hand a tester without pressing a button first, which is not what a "latest build" means. Pushes to master now refresh a `latest` pre-release in place. Both the tag and the asset name are stable, so the download URL never changes and a link given to a tester once keeps serving the current build. Release assets are public; Actions artifacts need an account, which is what made them useless for this. It stays the side-by-side variant: R8-minified like a real release, so it still exercises the minification that has broken Android builds here before, but signed with the debug keystore under the `.debug` applicationId. A bad master commit therefore cannot replace anyone's working install, and the production signing key stays in the tag-driven release workflow. Event handling is resolved in one step rather than read raw at each use. A push carries no dispatch inputs -- every `github.event.inputs.*` is empty on that event -- so the variant and ABI need real defaults, and the publish decision differs by event. Doing it once means the build, collect and publish steps cannot disagree about what the run is. Known gap, documented rather than hidden: this builds in parallel with build-and-test.yml, so `latest` can carry a commit whose tests later fail. Cross-workflow dependencies are not reliably available here and duplicating the test job would double an already hour-long queue on a single-slot runner.	2026-09-05 13:42:33 +02:00
dtourolle	b5a3a3b427	fix(ci): make the test-APK dispatch inputs work and stop it always publishing ... Two defects in a workflow that had never actually run. The publish guard was `if: ${{ inputs.publish }}`. A dispatch input arrives as a *string*, and every non-empty string is truthy in the expression language, so "false" is truthy too -- the workflow would have published a public pre-release on every run, including the ones where the box was deliberately left unticked. Now compared against 'true' explicitly. The bare `inputs.*` context is also newer than `github.event.inputs.*` and no other workflow here uses either, so nothing proved the short form works on this Gitea. Switched to the form both Gitea and GitHub have supported throughout; an unresolved context would have silently expanded to an empty string, sending every build down the `debug` branch and then failing to find a `*-debug.apk`.	2026-09-03 20:19:59 +02:00
dtourolle	10d77f1380	ci: publish a test APK as a pre-release for outside testers ... Gitea artifacts need an account with read access to download, which makes them useless for handing a build to someone outside the project -- the actual reason a test APK gets built in the first place. An optional publish input attaches the APK to a pre-release instead, whose assets are a plain public URL on a public repo. No merge to master, no MR, no version tag, and the tester needs no account. Safe from a feature branch on two counts. The tag is test-<branch> rather than v*, and only v* triggers build-release.yml, so nothing else reacts to it. And it cannot reach existing users: the desktop updater reads a static latest.json from the updater branch, not the release list. Re-dispatching the same branch replaces the APK on the existing pre-release rather than accumulating one release per attempt.	2026-08-30 20:06:40 +02:00
dtourolle	03c0b5cd17	ci: build a test APK from any branch on demand ... build-release.yml is tag-driven, builds three platforms and then creates a release -- none of which is what you want from a feature branch, and there was otherwise no way to get an installable build out of CI without cutting one. workflow_dispatch only, deliberately. The runner has a single slot shared with two other projects, so an APK on every feature-branch commit would starve them; dispatch it when you actually want to install something. Defaults to the R8-minified release build in the debug applicationId slot rather than a plain debug APK. Minification is where Android releases have actually broken here (R8 stripping JNI-loaded player and security classes), and a debug build cannot catch it. Neither variant needs the real signing key, and both install side by side with a real install. Builds through scripts/build-android.sh rather than a hand-rolled tauri invocation, so CI and a developer's machine produce the same thing and the script's applicationId assertion still runs. Shares the existing cargo registry cache key -- no fourth copy of the registry on a disk that has filled before.	2026-08-30 19:48:59 +02:00