Move latest open Android queues from 29 to 36#127250
Conversation
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
Updates Helix queue configuration to run “latest” Android testing on a newer API level, aligning CI coverage with newer Android platform cryptography APIs.
Changes:
- Bump Ubuntu-based open Android Helix queues from API 29 to API 36 for libraries pipelines.
- Update the Android “latest” platform alias in
helix-platforms.ymlto point at the API 36 queue. - Update CoreCLR template to use the API 36 open queue for public Android x64 runs.
Show a summary per file
| File | Description |
|---|---|
| eng/pipelines/libraries/helix-queues-setup.yml | Switches Ubuntu Android Open queue used by libraries jobs to API 36. |
| eng/pipelines/helix-platforms.yml | Updates helix_android_ubuntu_latest alias and its comment to API 36. |
| eng/pipelines/coreclr/templates/helix-queues-setup.yml | Updates public Android x64 Helix queue to API 36 Open. |
Copilot's findings
- Files reviewed: 3/3 changed files
- Comments generated: 1
|
Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger |
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| @@ -90,9 +90,9 @@ jobs: | |||
| # Use the Ubuntu-based Android queue for x86/x64/bionic_x64 on all projects, | |||
| # and also for arm/arm64/bionic_arm/bionic_arm64 on non-public projects (no internal Windows Android queue). | |||
| - ${{ if in(parameters.platform, 'android_x86', 'android_x64', 'linux_bionic_x64') }}: | |||
There was a problem hiding this comment.
It looks like the queue Ubuntu.2204.Amd64.Android.36.Open does not have emulators with android-x86 support so I suggest keeping x86 testing on the original queue.
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I think this will put some strain on Helix. The .29 queue can service both x86/x64 so we only need to spin up half of the VMs to service the same load. If you only want to temporarily test the new APIs I'd suggest opening a WIP PR which targets the new queue. There is some idea of running the Android emulator in Docker so we can move away from the "single-queue-per-API-level" design but it's not there yet. |
|
@akoeplinger what about adding it as an additional outerloop queue that doesn't run on PRs but only scheduled runs? I am not thrilled with checking in a bunch of cryptographic code that won't get validated periodically. |
|
yeah. we could also move Android x86 instead since afaik it won't be supported with coreclr anyway, correct @simonrozsival? |
According to @simonrozsival
|
|
@akoeplinger @vcsjones yes, coreclr will run only on x64, arm64, and armeabi-v7a |
|
@vcsjones I need to double check tomorrow, but I think the devices on the Windows.11.Amd64.Android.Open queue have (mostly) API 36. |
|
I could also go as low as API Level 33, if 33, 34, or 35 has better availability. |
|
I think the last API level where Google published x86 images was 30. it's not really about availability, those queues are backed by Azure scalesets so they'll spin up VMs as needed but it means if we send 200 workitems to two queues we'll need to spin up VMs on each (i.e. roughly double) versus handling the load on one queue a bit slower. I think if x86 Android is not going to be supported in basically a few months from now I'd just move that to scheduled runs and take what you have here. |
|
Windows.11.Amd64.Android.Open is device queue - it has physical host machines with physical devices - so it does not scale at will. But it should have enough capacity (it has ~200 devices in it). Currently the devices we have in that queue (and their API level)
And yes, I know it's a mess, I'm working on cleaning it up. |
This bumps our open Android queue from 29 to 36. The motivation for this is to support new cryptography APIs that appeared in API level 33, and we will want test coverage for those APIs.