-
Notifications
You must be signed in to change notification settings - Fork 345
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
[release/8.0] Stop testing on windows.10.amd64.android.open #15063
[release/8.0] Stop testing on windows.10.amd64.android.open #15063
Conversation
/backport to release/6.0 |
Started backporting to release/6.0: https://github.com/dotnet/arcade/actions/runs/10776745637 |
- backport of #15063 to release/6.0 - see dotnet/dnceng#1994 - use windows.11.amd64.android.open instead - was previously done as part of #14453 for release/9.0 Co-authored-by: Doug Bunting <6431421+dougbu@users.noreply.github.com>
@simonrozsival we're seeing strange errors when trying to use the windows.11 (new) queue with the Android phones. I tried googling for the error it gave: And found this: Do you know if this is something we should do? |
Ohhh, I also see this: @ilyas1974 these Android phones were attached to new PCs when they moved, right? So maybe we need to enable USB debugging or trust the machines from the phones? |
the odd thing here (unless we've been merging arcade release/8.0 changes on red) is this PR shouldn't actually be changing anything. we've all been testing on windows.11.amd64.android.open for quite a while. windows.10.amd64.android.open has been forwarded to that queue since mid-February |
- see dotnet/dnceng#1994 - use windows.11.amd64.android.open instead - was previously done as part of dotnet#14453 for release/9.0
af7a598
to
f0c0465
Compare
I see. Then maybe it's something about the test app we're sending there in the PR build (it's probably years old and somewhere in the |
I looked a bit deeper. Seems the |
Put another way, this could be a consistent problem with the queue that skipped tests hid |
It's possible the 6.0 branch differs a lot from 8.0 to be honest |
- Updating 'Microsoft.DotNet.XHarness.CLI': '8.0.0-prerelease.23477.1' => '8.0.0-prerelease.24452.3' - from build '20240902.3' of 'https://github.com/dotnet/xharness'
trying w/ a newer XHarness CLI I noticed release/8.0 doesn't have a subscription from dotnet/xharness. that said, the sub for release/6.0 has |
I noticed some time ago that 6.0/8.0 Arcade was not actually even going to arcade-validation so I guess we're careful about retriggering all 6.0 branches of all repos? (I don't know myself) Only we found out during servicing that required updates from Arcade never made it anywhere (like some token removal). So maybe we try to keep 6.0/8.0 branches low-traffic? XHarness has a problem of depending on Arcade while Arcade depends on it so keeping it alive will be an endless loop of non-updates going there and back. I think it's probably fine to keep it off. |
alright. /fyi I missed a sub from xharness into release/8.0 but it's set up the same as for release/6.0 — |
no change w/ newer XHarness CLI version 😦 any other suggestions @simonrozsival or @premun❓ |
f14971e
to
123bb05
Compare
@dougbu I tried the commands from the stackoverflow thread and they seem to work. But let's re-run the tests at least once or twice to see if we just didn't get lucky with some machines. |
Oops, there was an auto-complete |
To double check: