Uh oh!
There was an error while loading. Please reload this page.
consume MsQuic 2.1 for windows ARM64 builds - #73713
Conversation
ghost
commented
Aug 10, 2022
Tagging subscribers to this area: @dotnet/ncl Issue DetailsWe don't have Windows ARM pipeline for msquic transport. This change consumes ARM bits published by msquic directly.
|
wfurt
commented
Aug 10, 2022
btw |
wfurt
commented
Aug 11, 2022
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
rzikm
commented
Aug 11, 2022
I thought you had a PR to dotnet/msquic which would build the DLL for ARM so we could consume it as we do for x86/x64 |
karelz
commented
Aug 11, 2022
@rzikm building on arm is problematic - this is easiest route. Even for Linux we are looking into cross-compilation on our side. |
karelz
commented
Aug 11, 2022
Windows arm64 pipeline was cancelled - https://github.com/dotnet/runtime/runs/7782294163
|
wfurt
commented
Aug 11, 2022
It was not meant as permanent change. Sees like we don't have hardware so we will not get any windows arm tests @karelz. |
rzikm
commented
Aug 11, 2022
Tested locally on Volterra device: |
#73713 added Windows.11.Arm64.Open runs to check MsQuic functionality there, but currently, there is no HW servicing the queue and the ci job timeouts. This PR temporarily suspends runs on the queue until appropriate HW is deployed to helix.
We don't have Windows ARM pipeline for msquic transport. This change consumes ARM bits published by msquic directly.
(This does not allow us easily consume daily builds & fixes but that should OK for now)