[RunAllTests] Fix #3510: Set up Android SDK hermetically in GitHub Actions to workaround #3024 #3513
Conversation
This file contains 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
This attempts to move all common build environment setup bits to a common local action using GitHub composite actions per https://github.saobby.my.eu.orgmunity/t/path-to-action-in-the-same-repository-as-workflow/16952/2, https://github.blog/changelog/2020-08-07-github-actions-composite-run-steps/, and https://docs.github.com/en/actions/creating-actions/creating-a-composite-run-steps-action. This does not include any actual changes to the CI environment yet other than temporarily disabling the other expensive checks as part of testing these changes.
OpenJDK can use "9.0" as the version string instead of "1.9".
BenHenning
changed the title
This integrates the new action with Bazel tests in addition to the build. While the tests work fine with the current build tools, we should be consistent in how the environment is set up for CI workflows.
The new name specifically clarifies why this action isn't needed for the Bazel-only script runs (since they don't require the Android SDK bits).
|
@seanlip PTAL for codeowners change. I'm looking for someone from the Android team to perform a full review, as well. |
|
@anandwana001 mentioned that he's available to review this--updating assignments. |
|
Sg, thanks. @anandwana001 please reassign me once you've reviewed! |
|
Sure, waiting for CI to pass. |
|
@anandwana001 CI is passing now--PTAL when you get a chance. |
anandwana001
approved these changes
Jul 22, 2021
|
Thanks! |
|
Unassigning @anandwana001 since they have already approved the PR. |
seanlip
approved these changes
Jul 22, 2021
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.
Fix #3510
Fix part of #2692
Explanation
This PR introduces sufficient CI arrangement to hermetically set up the Android SDK for all Bazel-related workflows. This fixes #3510 by mitigating #3024 by forcing workflows to use an older build tools instead of the latest that's included in the GitHub CI environment. While the hermeticity is nice, it introduces about an extra minute to each Bazel workflow. We may want to consider moving back to GitHub's automatically updating environment longer term once Bazel is sufficiently stable. I've noted this in #1861.
The new setup is being used for both Bazel app builds & tests. Technically, this isn't needed for tests since they don't require dexing, but keeping a consistent and hermetic environment seems ideal for all Bazel-related workflows. Note that we're intentionally not using the new workflow for the script runs since they don't require the Android SDK. That being said, this does result in a CI behavioral change for all related Bazel workflows: it's forcing using SDK 28 instead of 30 or newer.
Note that this also fixes part of #2692 by introducing our first shareable local action & by isolating the common Bazel setup code to it. Note that local actions can only contain shell commands and not reference other actions, so we'll be a bit limited in how much we can share.
Finally, this can be validated by seeing the passing CI checks (particularly, the passing build test). I've also run all the test workflows since they've been changed here, but they're expected to stay passing.
Checklist