-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating android remote tools broke downstream projects #13409
Comments
The new tools use a newer aapt2 flag, so we just need to update the android sdk to build tools, with the latest 30.0.3:
@philwo can you update the build image? |
@ahumesky Will do! |
thanks! |
Is this still a P0 and has there been any progress? |
I reduced it to a P1 as I understand that the problematic changes were rolled back. Nevertheless I plan to build new images and containers this evening so it should be fixed then. 😊 |
hey philwo, have the images and containers been updated? |
Not yet, I'll get to it tomorrow, promise. |
Discussed with @ahumesky that the observed issue is not caused by an outdated version of build-tools, but because rules_jvm_external and android-testing pin their build version to 28.0.2:
I'll still upgrade the build-tools and remove the unused 29.x versions from our images, but for now at least we're not responsible for the issues ;) |
Remove `build_tools_version` and `api_level` to let `android_sdk_repository` automatically select the latest installed version. One of the fixes for bazelbuild/bazel#13409 (comment)
Thanks Phil! I've created pull requests to remove the hard-coded build_tools_version. Once those are merged I'll try submitting my original change again. |
Remove `build_tools_version` and `api_level` to let `android_sdk_repository` automatically select the latest installed version. One of the fixes for bazelbuild/bazel#13409 (comment)
*** Reason for rollback *** Downstream projects on bazelci have been updated to not hardcode the buildtools versions: #13409 (comment) *** Original change description *** Automated rollback of commit b6f87f1. *** Reason for rollback *** Breaks downstream bazel projects because AAPT2 needs to be updated in the build images: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/2010#2595dff6-44ac-4996-9b38-cdacf2842215 *** Original change description *** Updates Android remote tools to 0.23.0 to include Update remote android tools to include c3edf13. RELNOTES: None. PiperOrigin-RevId: 377971964
Bazel's Android tools requires Android Build Tools 30.0.0 or newer. See #13409 RELNOTES: The minimum Android build tools version for the Android rules is now 30.0.0 PiperOrigin-RevId: 378014192
@ahumesky Looks like the roll forward of 80feea0 did some breakage again: https://buildkite.com/bazel/bazel-auto-sheriff-face-with-cowboy-hat/builds/546
|
The VMs currently provide these versions:
rules_jvm_external should already been fixed to not hard code android build tools version, but from the error message:
It seems Bazel picked the oldest one by default? |
So the error itself is coming from 0e65273 where I updated the minimum required sdk tools. Bazel should be picking the latest version, as far as I know nothing has changed in that code in quite a while. Let me see if I can repro this problem locally. |
Ah, well for rules_jvm_external, there are several other workspace files in the examples directory that also hardcode the build tools version, e.g. etc |
…to let android_sdk_repository automatically select the latest installed version. See bazelbuild/bazel#13409
And it seems the reason that android testing failed is that CI ran on the commit just 1 before the fix: So that will presumably get fixed on its own when CI runs on a newer version of the android testing repo |
@ahumesky I see, do you know why Android Testing is failing with Bazel 4.1.0? |
Friendly ping - I still see multiple "Bazel requires Android build tools version 30.0.0 or newer, 28.0.2 was provided" failures, e.g. https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/2070#81fa8b3c-a2e5-4532-ad61-d28fa5729446 |
Looks like I missed one instance of the build tools version being hardcoded in the bazel examples repo: For the Android Testing repo, for some reason it's still getting a commit 1 before the fix, same as in the comment above (#13409 (comment)). How does the test infrastructure select the commit to clone at? And for rules_jvm_external, there are several examples that hardcode the build tools version that I didn't see. I'll remove those. By the way, I noticed a failure in Tensorflow resulting from aefd107 I created |
It select the last green commit in the pipeline with Bazel@latest release, because if it's already red, it doesn't make sense to test against that commit in downstream. Thanks for all the fixes! |
…to let android_sdk_repository automatically select the latest installed version. See bazelbuild/bazel#13409 (#210)
There are two open PRs failing on RBE, zipalign issue, https://buildkite.com/bazel/rules-jvm-external-examples/builds/1884#321c38ff-91c5-43fc-b54f-1a02316d3c91 Is this a infrastructure or caching problem? cc @philwo, @meteorcloudy |
This looks like the same issue in android/testing-samples#387 Related discussion: android/testing-samples#384 |
This is reappearing again. "Bazel requires Android build tools version 30.0.0 or newer, 28.0.2 was provided" @meteorcloudy Can you check what's going on? If the SDK is really installed on the CI, it should error out. |
The VMs now provide these versions:
Any ideas why the error "Bazel requires Android build tools version 30.0.0 or newer, 28.0.2 was provided" reappears? |
Fix for |
Thanks!! |
It's green already on CI! |
Remove `build_tools_version` and `api_level` to let `android_sdk_repository` automatically select the latest installed version. One of the fixes for bazelbuild/bazel#13409 (comment)
b6f87f1 broke a number of downstream projects (Bazel Examples, rules_jvm_external, Android Testing).
Example failure:
https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/2010#2595dff6-44ac-4996-9b38-cdacf2842215
We're issuing a rollback now, but perhaps the correct solution is to update AAPT2 on the buildbots before rolling forward?
The text was updated successfully, but these errors were encountered: