[main] Update dependencies from dotnet/arcade #80492
Conversation
…109.1 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 8.0.0-beta.23053.5 -> To Version 8.0.0-beta.23059.1
|
@dotnet/dnceng any idea why this second Maestro dependency PR was opened instead of adding commits to #80492? |
ViktorHofer
deleted the
darc-main-01fd21af-6ca8-461e-88a0-7464e3ec3fcf
branch
|
Sorry wrong link, I meant #80234 |
|
@ViktorHofer looking at the logs I have no clue, I see "Adding dependency flow event for c32383ee-d79c-4435-5b63-08d8d8feb47e with Created New PR" but no exceptions or clues why. Perhaps @riarenas can help? |
|
I've seen this in cases where maestro is not able to update an existing PR first, usually due to merge conflicts in the original PR, which make it impossible to push a new update to the branch until the conflicts have been resolved. We might need more logging on the actor side on why the decision to open a new PR was made? |
|
Discussing this with Viktor regarding another PR, I realized that I may have caused this by reimaging maestro prod. I think what happens is the "state" of live PR management is stored on the Service Fabric cluster, so it can be shared across the N nodes of the cluster, in special shared state. We hit Service 360 alerts for having out Server 2022 images insufficiently patched, so a week or so ago I initiated a reimage of these machines. In most cases the PRs weren't kept open long enough for this to matter but for certain super-long-running PRs this loss of state could result in recreating the PRs. This is somewhat of an educated guess but the timing lines up. Since this state was stored ON the service fabric machines and not in the maestro SQL DBs, it's susceptible to this (or even ephemeral disk loss, if the D:\ drive got used) It's relatively easily mitigated and a corner case (most repos don't leave dependency flow PRs open for several months) so I don't think there's any follow up needed. |
ghost
locked as resolved and limited conversation to collaborators
This pull request updates the following dependencies
From https://github.com/dotnet/arcade