ci: give the toolchain versions one source of truth - #363
Conversation
The Flutter version was copied into seven workflows, so a bump meant touching all of them. Workflows now install Flutter through the shared .github/actions/setup-flutter action, which reads .flutter-version. The JDK gets the same treatment: .java-version is the one place it lives, and setup-java reads it with java-version-file. The stale AGP/Gradle/Kotlin versions in the two Android workflow comments are gone — those numbers live in settings.gradle and gradle-wrapper.properties, not in a comment. Also puts actions/checkout on v5 everywhere (it was split v4/v5), protects .java-version from the CI fixer, and reports both pins in doctor.sh. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W8K9hCeP3CNwTNLwerxxRo
Fails if a workflow hardcodes a Flutter or JDK version again, if a workflow runs Flutter without the shared action, if an action ends up pinned to two different refs, or if a doc, comment or script names a Flutter/Gradle/AGP/ Kotlin/JDK version that disagrees with the file that owns it. Deliberately historical mentions (the arm64 reproducibility note, the license audit) are listed explicitly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W8K9hCeP3CNwTNLwerxxRo
The docs promised JDK 21 in four places while CI has been installing 17. development.md now has one table of every pin and the file that owns it, and the F-Droid docs point at those files instead of listing workflows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W8K9hCeP3CNwTNLwerxxRo
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 660b5ee446
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| _historicalVersions[f.path] ?? const <String>{}; | ||
| for (final RegExpMatch m in pattern.allMatches(_plain(f.text))) { | ||
| final String found = m.group(1)!; | ||
| if (historical.contains(found)) continue; |
There was a problem hiding this comment.
When a current-toolchain sentence in any file listed in _historicalVersions accidentally reuses one of that file's historical version numbers, this condition skips it solely on the (file, version) pair. For example, changing the current Flutter requirement in docs/fdroid-readiness.md to 3.27.4 would still pass, contradicting the intended guarantee that current statements in files containing historical notes remain checked. Identify the specific historical occurrence (such as by line or surrounding text) rather than exempting every occurrence of that version in the file.
Useful? React with 👍 / 👎.
2 participants
First step for #362: clean up where the toolchain versions live, before any update bot exists to bump them.
Right now the Flutter version is written out in seven workflows, the docs promise JDK 21 while CI installs 17, two Android workflow comments still advertise AGP 8.2.1 / Gradle 8.7 / Kotlin 1.9.24, and
actions/checkoutis split between v4 and v5.What changed:
.github/actions/setup-flutter, which reads.flutter-version— no workflow names the version anymore.java-versionowns the JDK, and everysetup-javastep reads it viajava-version-fileandroid/settings.gradleandgradle-wrapper.propertiesactions/checkoutis v5 everywhere (v5 is v4 on node24 — same inputs and defaults).java-versionis protected from the CI fixer like.flutter-versionis, anddoctor.shreports both pinsdevelopment.mdnow has one table of every pin and the file that owns it, and the JDK references are corrected to 17The guardrails live in
test/tooling/toolchain_pins_test.dartand fail if:That last one is what caught the JDK 21 drift. Mentions that are deliberately historical (the arm64 reproducibility note, the license audit) are listed one by one in the test instead of whole files being skipped, so the current-toolchain sentences in those same files stay checked.
Verified locally on the pinned 3.44.7:
flutter pub get --enforce-lockfile,dart format --set-exit-if-changed .,flutter analyze,flutter test(3190 passing, including the F-Droid release guardrails) andscripts/check_secrets.sh. I also mutated each pin one at a time to confirm the new test actually fails on drift.No app code,
pubspec.lock, metadata or version changes, so the F-Droid build inputs are untouched.No Dependabot or update workflow in here — that's the next PR.
Part of #362
Generated by Claude Code