The workflow only triggered on push and pull_request, so a run that failed for
reasons outside the repo — runner down, toolchain changed underneath it —
could only be retried with an empty commit. That is a likelier situation with a
self-hosted runner than with hosted ones.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Targets runs-on: flutter-android for both jobs. Since that runner is host mode
with the toolchain preinstalled, subosito/flutter-action and
actions/setup-java are removed — they would have downloaded a second Flutter
and JDK over the ones being used, and CI would no longer be building with the
toolchain the release was verified against. A Toolchain step fails loudly if
flutter or ANDROID_HOME is missing rather than letting a later step fail
obscurely.
Documents in docs/README.md why the runner cannot be the Gitea host, what host
mode trades away, and what each job protects — including why building the
release APK is necessary but not sufficient, which is the reason the JNI name
guard exists at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CI only ran analyze and test, so it would have passed for every commit that
carried the broken release APK. Adds a release-apk job that builds the
minified artifact, runs tool/check_jni_keep_rules.sh against it, and uploads
it — turning "the shipping artifact works" into something checked rather than
assumed at tag time.
Enables flutter-action's dependency cache on both jobs, and notes that the
test step now includes the layering guard.
This does not fix the current failures: every run so far has failed at
actions/checkout, before Flutter is reached, because the runner's job
containers cannot resolve the `gitea` hostname. That is runner configuration,
not workflow content.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Add GitHub Actions CI workflow for analyze and tests
- Update README with project structure, build instructions, and license info
- Document iperf3 binary bundling process
mikkeli
irene