When do repo changes move to dotnet/dotnet?

[tmds]

@MichaelSimons @mthalman I'm keeping my eye on a change that was merged in the sdk 8.0.1xx branch last week to become available in the dotnet/dotnet repo.

This made me wonder: what controls when changes arrive in dotnet/dotnet repo?

cc @omajid

[mthalman]

The dotnet/installer repo controls what ends up in dotnet/dotnet (VMR). Any time a commit is made in installer, a synchronization pipeline runs which updates the VMR to reflect that change. The installer repo defines references to all of its dependencies in Version.Details.xml. Its actually a graph of dependencies since each of those dependencies has its own set of dependencies. The repos that are represented in the VMR are synced according to the commits referenced in these dependencies.

In order to know when a particular change makes it way to be available from the installer repo, you'd need to track the dependency flow. For example, this PR was just merged which represents the dependency flow of the sdk repo into installer.

[tmds]

For example, this dotnet/installer#17319 which represents the dependency flow of the sdk repo into installer.

What triggers dotnet-maestro to make this PR?

[MichaelSimons]

A successful build is what triggers the dependency flow. Note flows have a knob for how frequently they should run (every build, daily, weekly, manually) so there is variability dependency on the subscription.

[tmds]

Note flows have a knob for how frequently they should run (every build, daily, weekly, manually) so there is variability dependency on the subscription.

I was thinking there probably is a time trigger because someone changing code in the sdk repository without there being a change in dependencies with other repos, should still trigger those changes to be pulled in.

Thanks for answering my questions. I have a basic grasp. To get a full understanding I should read https://devblogs.microsoft.com/dotnet/the-evolving-infrastructure-of-net-core/#maestro-and-dependency-flow.