-
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
[main] Update dependencies from dotnet/runtime #26470
[main] Update dependencies from dotnet/runtime #26470
Conversation
…0706.9 Microsoft.DotNet.ILCompiler , Microsoft.Extensions.DependencyModel , Microsoft.NET.HostModel , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.App.Ref , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.DotNetHostResolver , Microsoft.NETCore.Platforms , System.CodeDom , System.Reflection.MetadataLoadContext , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.7.0 , VS.Redist.Common.NetCore.TargetingPack.x64.7.0 From Version 7.0.0-preview.6.22356.1 -> To Version 7.0.0-preview.6.22356.9
Notification for subscribed users from https://github.com/dotnet/runtime:@dnr-codeflow Action requested: Please take a look at this failing automated dependency-flow pull request's checks; failures may be related to changes which originated in your repo.
|
…0738762-11d1-4f67-ac23-7d84d59127d1
…0707.4 Microsoft.DotNet.ILCompiler , Microsoft.Extensions.DependencyModel , Microsoft.NET.HostModel , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.App.Ref , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.DotNetHostResolver , Microsoft.NETCore.Platforms , System.CodeDom , System.Reflection.MetadataLoadContext , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.7.0 , VS.Redist.Common.NetCore.TargetingPack.x64.7.0 From Version 7.0.0-preview.6.22356.1 -> To Version 7.0.0-preview.6.22357.4
…0708.7 Microsoft.DotNet.ILCompiler , Microsoft.Extensions.DependencyModel , Microsoft.NET.HostModel , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.App.Ref , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.DotNetHostResolver , Microsoft.NETCore.Platforms , System.CodeDom , System.Reflection.MetadataLoadContext , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.7.0 , VS.Redist.Common.NetCore.TargetingPack.x64.7.0 From Version 7.0.0-preview.6.22356.1 -> To Version 7.0.0-preview.7.22358.7
@mmitche, @hoyosjs, the bot opened this pr at the time when main branch was broken ( is there anything which can be done to improve the process and make it as automated as possible? like make bot to merge target branch to pr's source branch when pushing the new commit. if there is a merge conflict, close the pr and start fresh from tip of the target branch. |
My PR dotnet/runtime#66304 will remove It will need something like 68a51c7 |
Runtime progress is currently blocked by |
@pavelsavara could you merge main to darc-main-b0738762-11d1-4f67-ac23-7d84d59127d1? it will at least unblock this pr |
Looks like something has changed in the runtimeconfig.json format recently. Helix work items are also timing out a lot. |
The timeouts are likely infrastructure/networking. There is a test that was updated to target the current runtime but the test then requires the exact runtime build (so needed to be fixed with each insertion). I tried reverting it back to net6.0 and we'll see if that helps. |
The legs that ran, passed. Some of the legs failed to even find a machine and rerunning those now. |
@mmitche, @hoyosjs, @kasperk81 is there any followup here? @marcpopMSFT pointed out this codeflow was slower than normal. |
Looking at the timeline, this was opened July 7th (Thursday) and failed (pinging the dnr-codeflow team), then my vendor tried to fix by merging with main on July 8th, then folks engaged on July 10th (Sunday) and got the merge fixed then, I engaged yesterday when some sdk test issue was identified, and we got it merged. I think the concern from tactics is that aspnet was blocked flowing into installer so this being delayed 5 days put aspnet even further behind. So the question is what could have happened those first two days to improve our speed on these? |
can we automate this bit? say the bot can try to merge target branch (main) to active darc branches when it is updating the existing branch again (for runtime it happens once a day). it may not "fix" everything, but it will avoid the mandatory manual/human action in cases when main was broken at the time of creation of darc branch by bot, and then main gets fixed subsequently. alternatively, some ci systems (before devops when dotnet repositories were using Jenkins) merge source to target branch after the git checkout, we can configure devops to do the same. |
that's awesome. assuming devops checkout that merge commit during ci runs for ongoing prs, then we don't need any action for this. |
Yeah, I don't know why the merge with main was done (maybe there was a merge conflict that couldn't be resolved in the UI) as every new change should run the build with fully merged sources. |
This pull request updates the following dependencies
From https://github.com/dotnet/runtime