-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[manual] Merge release/7.0-staging into release/7.0 #86296
[manual] Merge release/7.0-staging into release/7.0 #86296
Conversation
…inker dotnet/emsdk dotnet/icu (dotnet#84648) * Update dependencies from https://github.com/dotnet/arcade build 20230411.2 Microsoft.DotNet.ApiCompat , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions From Version 7.0.0-beta.23164.3 -> To Version 7.0.0-beta.23211.2 * Update dependencies from https://github.com/dotnet/linker build 20230411.1 Microsoft.NET.ILLink.Tasks From Version 7.0.100-1.23207.1 -> To Version 7.0.100-1.23211.1 * Update dependencies from https://github.com/dotnet/emsdk build 20230411.1 Microsoft.NET.Workload.Emscripten.net6.Manifest-7.0.100 , Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100 From Version 7.0.6 -> To Version 7.0.6 * Update dependencies from https://github.com/dotnet/icu build 20230411.1 Microsoft.NETCore.Runtime.ICU.Transport From Version 7.0.0-rtm.23115.1 -> To Version 7.0.0-rtm.23211.1 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…dotnet#84641) There are a couple of places where we read the _continuation field and then read some other state which we assume to be consistent with the value we read in _continuation. But without a fence, those secondary reads could be reordered with respect to the first. Co-authored-by: Stephen Toub <stoub@microsoft.com>
…/7.0-to-release/7.0-staging [automated] Merge branch 'release/7.0' => 'release/7.0-staging'
Co-authored-by: Chris Sienkiewicz <chsienki@microsoft.com>
….4 (dotnet#85005) Microsoft.NETCore.Runtime.ICU.Transport From Version 7.0.0-rtm.23211.1 -> To Version 7.0.0-rtm.23218.4 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…dotnet#85074) * [PERF] Remove Android Maui Scenarios from Runtime Repo (dotnet#81453) Remove references to Maui Android testing as the testing for it has moved to the performance repo. * Removed pipeline dependencies and steps for running Maui-iOS as it has been moved to the performance repo. (dotnet#84363) * Remove commented out code. * Completely remove maui net6 and net7 build scripts.
Co-authored-by: Andrew Au <andrewau@microsoft.com>
…dotnet#85352) Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…ook for it first (dotnet#85270) The unmanaged native library probing documentation says to try absolute paths without variations https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing#unmanaged-native-library-probing Co-authored-by: Aleksey Kliger <alklig@microsoft.com>
… to release/7.0 (dotnet#84495) * Ported over changes from PR: 84339 to release/7.0 * used the MAX_YP_SPIN_COUNT_UNIT variable instead of the hardcoded value
Co-authored-by: Juan Sebastian Hoyos Ayala <juan.s.hoyos@outlook.com>
…/7.0-to-release/7.0-staging [automated] Merge branch 'release/7.0' => 'release/7.0-staging'
…#84856) Co-authored-by: carlossanlop <1175054+carlossanlop@users.noreply.github.com>
…et#85726) Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Premek Vysoky <premek.vysoky@microsoft.com>
…tnet#85656) * Make WindowsServiceLifetime gracefully stop (dotnet#83892) * Make WindowsServiceLifetime gracefully stop WindowsServiceLifetime was not waiting for ServiceBase to stop the service. As a result we would sometimes end the process before notifying service control manager that the service had stopped -- resulting in an error in the eventlog and sometimes a service restart. We also were permitting multiple calls to Stop to occur - through SCM callbacks, and through public API. We must not call SetServiceStatus again once the service is marked as stopped. * Alternate approach to ensuring we only ever set STATE_STOPPED once. * Avoid calling ServiceBase.Stop on stopped service I fixed double-calling STATE_STOPPED in ServiceBase, but this fix will not be present on .NETFramework. Workaround that by avoiding calling ServiceBase.Stop when the service has already been stopped by SCM. * Add tests for WindowsServiceLifetime These tests leverage RemoteExecutor to avoid creating a separate service assembly. * Respond to feedback and add more tests. This better integrates with the RemoteExecutor component as well, by hooking up the service process and fetching its handle. This gives us the correct logging and exitcode handling from RemoteExecutor. * Honor Cancellation in StopAsync * Fix bindingRedirects in RemoteExecutor * Use Async lambdas for service testing * Fix issue on Win7 where duplicate service descriptions are disallowed * Respond to feedback * Fix comment and add timeout * Fix test condition * Enable M.E.H.WindowsServices and S.SP.ServiceController for servicing * Make service wait on its state before stopping (dotnet#84447) * Fix WindowsService Tests where RemoteExecutor is unsupported * Enable MS.W.C for servicing * Reference latest Microsoft.Extensions.Logging.Abstractions This package has been serviced and we compile against the serviced version of its assemblies. None of the directly referenced projects have been serviced so our package doesn't restore the serviced versions. Lift up the dependency on Logging.Abstractions to ensure we reference the serviced package. --------- Co-authored-by: Vladimir Sadov <vsadov@microsoft.com>
Adding more details to our servicing documentation, particularly around the check-servicing-labels CI leg. Co-authored-by: Juan Hoyos <19413848+hoyosjs@users.noreply.github.com>
Co-authored-by: Daniel Ramos <danielramos@dsomar20.redmond.corp.microsoft.com>
…otnet#85784) Co-authored-by: pavelsavara <pavel.savara@gmail.com> Co-authored-by: Ilona Tomkowicz <itomkowicz@microsoft.com>
* Add test for literal field without name reference * Fix header name buffer allocation * Add more tests * Unified QPackDecoderTest test files * Fix variable name * Fixed HPackDecoder and ported QPack tests * Feedback --------- Co-authored-by: Bruno Blanes <bruno.blanes@outlook.com>
…11.1 (dotnet#86126) Microsoft.NET.Workload.Emscripten.net6.Manifest-7.0.100 , Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100 From Version 7.0.6 -> To Version 7.0.7 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Fixup data can assist native debugging tools in providing more accurate data (cherry picked from commit 4c814fa) Co-authored-by: Andy Gocke <angocke@microsoft.com>
…net#84444) Fix DBI loading problem on Linux (dotnet#82461)
…s with '-' in the base part. (dotnet#86282) * Microsoft.NETCore.Platforms: support adding rids with '-' in the base part. Currently when trying to add a rid like 'linux-musl-x64' the rid is not understood to be base = 'linux-musl', arch = 'x64'. Instead the parser considers a potential optional qualifier. This causes the rid to be parsed as base = 'linux', arch = 'musl', and qualifier = 'x64'. We know the rids being added won't have a qualifier. If we take this into account while parsing, we can parse the rid correctly. * Update src/libraries/Microsoft.NETCore.Platforms/src/RuntimeGroupCollection.cs Co-authored-by: Eric StJohn <ericstj@microsoft.com> --------- Co-authored-by: Tom Deseyn <tom.deseyn@gmail.com> Co-authored-by: Eric StJohn <ericstj@microsoft.com>
There are some CI failures in WASM and Mono that I am seeing for the first time. @lewing, @steveisok, @radical, @akoeplinger do they look familiar to you?: Affected queues:
Failures:
Affected queues:
Failure:
Affected queues:
Failure:
Note: This failure in all-configurations is expected until we push to nuget the OOB packages generated last month:
|
We have one more RID incoming. The CI will be reset. |
* Add Ubuntu 23.10 (Mantic Minotaur) RIDs * library Microsoft.NETCore.Platforms - added RIDs to runtime.compatibility.json - added RIDs to runtime.json - added Mantic Version Id to Ubuntu runtimeGroups.props - incremented ServicingVersion in Microsoft.NETCore.Platforms.csproj * Update src/libraries/Microsoft.NETCore.Platforms/src/Microsoft.NETCore.Platforms.csproj --------- Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>
The wasm failures look trimming related and like something @sbomer or @vitek-karas was aware of? |
That will not happen till June. |
@carlossanlop you can disable the failing validation meanwhile by adding the packages here:
|
This reverts commit 1182123.
This is a problem in the fsharp ILLink.Substitutions.xml. It is being fixed in dotnet/fsharp#14395. You can work around it like we do in these runtime tests: runtime/src/libraries/System.Formats.Cbor/tests/System.Formats.Cbor.Tests.csproj Lines 7 to 8 in ddd748e
|
Why does this error show up in the merge PR only? |
All those errors showed up in the runtime-extra-platforms CI legs, which got executed automatically in this PR. I had not seen these legs being executed manually or automatically in any servicing PR from the past month. |
Failures in the latest run are known. I think it's good to merge.
|
Merge commit.