| If attempting to reproduce a build failure results in a successful build, here are some possibilities: | |
| Was the previous failure that you observed in Android Studio? This script cannot necessarily reproduce errors from the editor | |
| A) You could ask a teammate for help | |
| The build may be nondeterministic | |
| A) ab-damage-estimator can search for examples of this error on build servers https://dashboards.corp.google.com/_d7c29bbb_d22c_4d60_833b_98f096f089e7?f=branch:in:aosp-androidx-main&f=day:pd:90 | |
| B) Develocity can search for examples of this error on developer computers https://ge.androidx.dev/scans/failures | |
| To upload your own build scan data, see https://g3doc.corp.google.com/company/teams/androidx/onboarding.md?cl=head#gradle-build-scans | |
| C) You could run the build in a loop, in hopes of reproducing the error again | |
| D) You could upload a build scan for a failure from the build server via development/publishScan.sh | |
| Build scans sometimes have different information than error logs. | |
| Build scans can also be directly compared using Develocity (the server that hosts them) | |
| The state of your build could be different from when you started your previous build | |
| Running the failing build may have deleted the problematic state (cleared caches etc) | |
| A) Next time, you could make a backup of the build state ( development/diagnose-build-failure/impl/backup-state.sh ) before the failure occurs and compare to the build state after the failure occurs | |