Merging internal commits for release/3.1#43136
Conversation
…ng/internal/dotnet-coreclr This pull request updates the following dependencies [marker]: <> (Begin:e602b4c3-5c4b-44ff-d44b-08d76e1d3434) ## From https://dev.azure.com/dnceng/internal/_git/dotnet-coreclr - **Subscription**: e602b4c3-5c4b-44ff-d44b-08d76e1d3434 - **Build**: 20220102.2 - **Date Produced**: January 3, 2022 5:25:41 AM UTC - **Commit**: a9acf95fd9954ecec99f12566ff261e16ff4130a - **Branch**: refs/heads/internal/release/3.1 [DependencyUpdate]: <> (Begin) - **Updates**: - **Microsoft.NET.Sdk.IL**: [from 3.1.22-servicing.21568.3 to 3.1.23-servicing.22052.2][3] - **Microsoft.NETCore.ILAsm**: [from 3.1.22-servicing.21568.3 to 3.1.23-servicing.22052.2][3] - **Microsoft.NETCore.Runtime.CoreCLR**: [from 3.1.22-servicing.21568.3 to 3.1.23-servicing.22052.2][3] [3]: https://dev.azure.com/dnceng/internal/_git/dotnet-coreclr/branches?baseVersion=GC28bb6f9&targetVersion=GCa9acf95&_a=files [DependencyUpdate]: <> (End) [marker]: <> (End:e602b4c3-5c4b-44ff-d44b-08d76e1d3434)
…o address CVE-2020-8927 [Component Governance](https://dnceng.visualstudio.com/internal/_componentGovernance/dotnet-corefx/alert/5549446?typeId=8301794) identified that we have an insecure version of Brotli in place for .NET Core 2.1, .NET Core 3.1, and .NET 5.0. The vulnerability is surfaced in the BrotliDecoderDecompress method which is used by .NET in our BrotliDecoder.TryDecompress public API. This addresses MSRC 70024. This change was created by backporting the brotli contents as updated in dotnet/runtime#44107, which updated Brotli to v1.0.9 in .NET 6.0 for performance optimizations.
…otnet-coreclr build 20220216.1 Microsoft.NET.Sdk.IL , Microsoft.NETCore.ILAsm , Microsoft.NETCore.Runtime.CoreCLR From Version 3.1.23-servicing.22052.2 -> To Version 3.1.23-servicing.22116.1
…rors coming from the internal repos
Revert "adding a bunch more duplicates of dotnet3 in hopes of delaying the errors coming from the internal repos" This reverts commit 9fbce46. Revert "reordered package sources" This reverts commit 01b4f91. Revert "moved automated package source section below static package sources" This reverts commit 131ce76.
… to be one that exists.
…ng/internal/dotnet-coreclr This pull request updates the following dependencies [marker]: <> (Begin:e602b4c3-5c4b-44ff-d44b-08d76e1d3434) ## From https://dev.azure.com/dnceng/internal/_git/dotnet-coreclr - **Subscription**: e602b4c3-5c4b-44ff-d44b-08d76e1d3434 - **Build**: 20220216.1 - **Date Produced**: February 17, 2022 12:48:34 AM UTC - **Commit**: 0dee78f90fc80c0fa4390ac1ba519c679bd503a4 - **Branch**: refs/heads/internal/release/3.1 [DependencyUpdate]: <> (Begin) - **Updates**: - **Microsoft.NET.Sdk.IL**: [from 3.1.23-servicing.22052.2 to 3.1.23-servicing.22116.1][1] - **Microsoft.NETCore.ILAsm**: [from 3.1.23-servicing.22052.2 to 3.1.23-servicing.22116.1][1] - **Microsoft.NETCore.Runtime.CoreCLR**: [from 3.1.23-servicing.22052.2 to 3.1.23-servicing.22116.1][1] [1]: https://dev.azure.com/dnceng/internal/_git/dotnet-coreclr/branches?baseVersion=GCa9acf95&targetVersion=GC0dee78f&_a=files [DependencyUpdate]: <> (End) [marker]: <> (End:e602b4c3-5c4b-44ff-d44b-08d76e1d3434)
…-merge-3.1-2022-03-08-1132
Does that mean we need to update the queue we're sending something to? Or just keep jamming on retry? |
I'm thinking one of the target queues is no longer available. I think it's |
|
It looks like other Windows configurations ran seem to have hit two distinct failures, Since the queue error isn't caused by this syncup, it feels like we should just take the merge and fix things directly on the release/3.1 branch. Thoughts? |
|
We can merge it. That's fine. I did add a change removing the nano queue. We can revert that first if necessary. |
Known intermittent issue dotnet/runtime#62068, you can ignore. |
Yeah, that queue is definitely gone. I think we have some docker containers that could be used, but otherwise it should be removed. |
We shouldn't ignore these. I'll put up a separate PR to bring the test fix back. dotnet/runtime@100618b. Posted #43137 |
|
Builds are succeeding. All failures here are tests. Thanks for merging @vseanreesermsft
OSX failures: |
If you want to send work to similar queues, you'd use (What this means is using the newer docker-based means of referencing Nano on a normal Windows, versus actually running Helix in Nano, which was problematic) That said, I don't think we'd be fixing any issues arising from only being broken on Nano, so the "right thing to do" is likely to remove usage. |
No description provided.