-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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/10.0.1xx-preview1] Update dependencies from nuget/nuget.client #46361
[release/10.0.1xx-preview1] Update dependencies from nuget/nuget.client #46361
Conversation
…6.14.0.14 Microsoft.Build.NuGetSdkResolver , NuGet.Build.Tasks , NuGet.Build.Tasks.Console , NuGet.Build.Tasks.Pack , NuGet.CommandLine.XPlat , NuGet.Commands , NuGet.Common , NuGet.Configuration , NuGet.Credentials , NuGet.DependencyResolver.Core , NuGet.Frameworks , NuGet.LibraryModel , NuGet.Localization , NuGet.Packaging , NuGet.ProjectModel , NuGet.Protocol , NuGet.Versioning From Version 6.14.0-preview.1.11 -> To Version 6.14.0-preview.1.14
Probably the change to not prune packages if there are no FrameworkReferences reverted this to the old behavior
…6.14.0.15 Microsoft.Build.NuGetSdkResolver , NuGet.Build.Tasks , NuGet.Build.Tasks.Console , NuGet.Build.Tasks.Pack , NuGet.CommandLine.XPlat , NuGet.Commands , NuGet.Common , NuGet.Configuration , NuGet.Credentials , NuGet.DependencyResolver.Core , NuGet.Frameworks , NuGet.LibraryModel , NuGet.Localization , NuGet.Packaging , NuGet.ProjectModel , NuGet.Protocol , NuGet.Versioning From Version 6.14.0-preview.1.11 -> To Version 6.14.0-preview.1.15
…6.14.0.17 Microsoft.Build.NuGetSdkResolver , NuGet.Build.Tasks , NuGet.Build.Tasks.Console , NuGet.Build.Tasks.Pack , NuGet.CommandLine.XPlat , NuGet.Commands , NuGet.Common , NuGet.Configuration , NuGet.Credentials , NuGet.DependencyResolver.Core , NuGet.Frameworks , NuGet.LibraryModel , NuGet.Localization , NuGet.Packaging , NuGet.ProjectModel , NuGet.Protocol , NuGet.Versioning From Version 6.14.0-preview.1.11 -> To Version 6.14.0-preview.1.17
@dotnet/source-build Some kind of synchronization issue. |
/azp run dotnet-sdk-public-ci |
Azure Pipelines successfully started running 1 pipeline(s). |
Patch conflict as it is not needed anymore - will remove it. |
New error in vmr sync is strange:
@premun can you help? This file was being modified with a patch, which I've now removed. What would be the root cause of this failure? Branch |
@dkurepa Was working on the sync issue and may have it figured out tomorrow. |
@NikolaMilosavljevic I think it is a combination of those two and the CRLF EOLs while synchronizing on Linux, yes. |
…review1-0ea97523-6b79-49bf-a1c9-6a3616027ea2
Oh, I noticed the patch contains 2 updates to the same file ( |
This might help with the VMR sync problems we have in dotnet/sdk#46361
4862a5b
to
1066240
Compare
1066240
to
1314631
Compare
VMR sync worked after I added a second, dummy, patch. I presume this needs to be updated to unblock future syncs, is that correct? |
@NikolaMilosavljevic yeah, your dummy patch worked but then you merged main and it stopped working again so I tried to resolve it with a single patch but had a few attempts where my git UI client generated invalid patches. |
@NikolaMilosavljevic the latest commit seems to work - it just removes the offending line that had the spaces |
@premek @NikolaMilosavljevic It looks like there's still a VMR sync error here. What do we need to do next to get this merge? |
@premun Wrong Přemek :) |
…review1-0ea97523-6b79-49bf-a1c9-6a3616027ea2
I honestly don't understand what's going on here. The stage 1 job succeeds and the same container running the same image fails in the stage 2 job.. |
@NikolaMilosavljevic I believe you are unblocked now |
This looks like a potentially new NuGet check flowing in that is causing a build failure. The Stage 2 builds use the sdk/toolset built with stage 1. If new rules are added, they will expose any failures in stage 2.
This warning/error can be suppressed in SBRP to workaround the issue. |
@MichaelSimons I expect more repositories to be impacted by NU1510. Any project that has a direct dependency on a pruned package would hit this. If you have time, sure start with SBRP and then fix case by case but I don't think that's a realistic option at this point for P1. Updating
|
I am onboard with disabling across the board for P1. |
Alternatively, it's also possible to disable the packaging pruning feature via a feature knob: |
I'd expect We should not disable pruning. |
Let's just no warn NU1510 temporarily. I think this is likely to become noisy. This might be one of the candidates that we need to discuss whether to keep. I'm tracking that effort in https://github.com/nuget/client.engineering/issues/3111. |
We agreed on suppressing NU1510 temporarily for P1 (this PR) and use the main dependency flow PR (#46290) to look into this more deeply to see how many repositories are affected. Given that we have been doing a lot of work over the last months and years to get rid of netstandard1.x packages in most of our core stack repositories, I don't expect a ton of warnings. |
New warnings/errors about NU1511 now:
|
This pull request updates the following dependencies
From https://github.com/nuget/nuget.client