Repository navigation
docs: say that an Android test run after a branch switch needs --no-build-cache --rerun-tasks - #2458
Merged
Merged
Conversation
…uild-cache --rerun-tasks Gradle's cache is keyed on inputs it can see, and a branch switch can leave generated sources, Room DAOs and KSP output, from the previous branch in place. The suite then runs against code that is not the code checked out, and reports failures in classes the contributor never touched. Nothing contributor-facing said so. CONTRIBUTING, the pull-request template, AGENTS and android/README all give the bare `./gradlew testFullDebugUnitTest`, and the flags appear in none of them. The cost is not hypothetical. Two contributors in two days have filed pull requests containing a paragraph explaining away Android failures as pre-existing on main: one reported two failures in RecoveryDriversTest, the other eight across RecoveryDrivers, StandardHrSensorFormat, StepsDetailIntegration and TodayExplainability, described as "the same failures as untouched upstream/main". Main is green: the same suite runs 6430 tests with no failures here, and CI has been green throughout. Both of them spent time on it, then wrote a defence of their own branch into a PR body, for a cache artefact nobody had told them about. So it is written in all four places a contributor might look, with the reason rather than only the incantation, and with the actionable form: re-run clean before concluding a red test is pre-existing on main. The docs state the MECHANISM as a possibility and stop there. Whether stale generated sources explain those particular failures is not established: RecoveryDrivers is pure arithmetic with no Room or KSP dependency, so a stale DAO is not an obvious cause for it. What is established is that the suite is green here and in CI, and that the flags are required after a branch switch in this repo. The permanent docs say only that; the incident belongs in this pull request, where it is the reason for the change rather than a diagnosis of anyone's environment.
ryanbr
force-pushed
the
rb-gradle-docs
branch
from
September 25, 2026 11:25
a154eff to
15fde5a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Gradle's cache is keyed on inputs it can see, and a branch switch can leave generated sources, Room DAOs and KSP output, from the previous branch in place. The suite then runs against code that is not the code you have checked out, and reports failures in classes your change never touched.
Nothing contributor-facing said so.
CONTRIBUTING.md, the pull-request template,AGENTS.mdandandroid/README.mdall give the bare./gradlew testFullDebugUnitTest, and--no-build-cache --rerun-tasksappears in none of them.Why now
The cost is not hypothetical. Two contributors in two days have filed pull requests containing a paragraph explaining away Android failures as pre-existing on main:
RecoveryDriversTestRecoveryDrivers,StandardHrSensorFormat,StepsDetailIntegrationandTodayExplainability, described as "the same failures as untouchedupstream/main"Main is green. The same suite runs 6430 tests with no failures here, and CI has been green throughout. Both contributors spent time on it, then wrote a defence of their own branch into a PR body, for a cache artefact nobody had told them about. Neither was doing anything wrong.
The change
The flags are now in all four places a contributor might look, with the reason rather than only the incantation, and with the specific advice that a failure only you can see is usually this. CI always builds clean, which is why it never shows there.
Docs only. No code, no workflow change.