Proposed tasks to improve the OOB nuget build process in servicing branches

[carlossanlop]

The following items were discussed with @ViktorHofer and @smasher164 to improve the overall experience of servicing code from an OOB package.

Resetting GeneratePackageOnBuild to false

Currently, we reset the <GeneratePackageOnBuild> property of OOB csproj files to false in the branding PRs that get created every month when the servicing branches are opened.

If someone submits a servicing PR that modifies a package that depends on another OOB package that had its version bumped the previous month, the CI will start showing a failure in AllConfigurations stating that the nuget dependency is not found in nuget.org.

This happens because the nuget packages created the previous month have not yet been pushed to nuget (this is expected) due to the previous month's GA date (which is the day we push them) happening after the current month's Code Complete date.

The problem gets worse if we end up merging such PR, because now the failure propagates to the servicing rolling builds and subsequent PRs.

Here is an example: #81914

To prevent this problem in the future, we have decided to separate branding from resetting the property. Here are two tasks to achieve this:

• We will write a GitHub action to automatically create a PR that finds all the csproj files under src/libraries that belong to OOB packages, and change <GeneratePackageOnBuild> to false.
• We will trigger such GitHub action at the same time as the branding PRs are created. We would like to modify the branding scripts created by @vseanreesermsft to achieve this.

These PRs would be the last ones we would merge on the Code Complete day. We will also be able to consider the official closing of the servicing branches for that month. Doing this will prevent having the servicing rolling builds and the PR CI runs in red due to nuget failures. Note: we might have some servicing rolling builds failing, but once the nuget packages get pushed, they should go away. Additionally, we will request the possibility of aligning the GA and Code Complete dates, to prevent red builds completely.

Fail when a Microsoft.Windows.Compatibility dependency is modified

The M.W.C. package is a package with no source code that depends on a bunch of other packages. If a new version of one of its dependencies gets built, we need to make sure to also build a new version of M.W.C., and push both new packages to nuget. We currently don't have an easy way to remind ourselves to do this, and it has already happened in the past that we forget to build M.W.C. and we only hear about it after a customer asks for the update.

To prevent forgetting, we have decided to take some steps:

• Implement the validation target proposed in Consider shipping Microsoft.Windows.Compatibility with every servicing release #77557 by @ericstj, which would emit a build error when a package that M.W.C. depends on gets the <GeneratePackageOnBuild> property set to true, but M.W.C. itself does not.
• Improve the documentation of M.W.C. in 6.0 and 7.0 to describe in more detail the need to set the property to true for M.W.C. if a dependency is built.
  • 6.0: [release/6.0] Improve servicing docs for Microsoft.Windows.Compatibility #81800
  • 7.0 [release/7.0] Improve servicing docs for Microsoft.Windows.Compatibility #83557
  • [] main - This is changing due to System.Drawing
• Create a dependabot task that takes care of updating the versions of the M.W.C. external dependencies in Versions props when they change.

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The following items were discussed with @ViktorHofer and @smasher164 to improve the overall experience of servicing code from an OOB package.

Reseting GeneratePackageOnBuild to false

Currently, we reset the <GeneratePackageOnBuild> property of OOB csproj files to false in the branding PRs that get created every month when the servicing branches are opened.

If someone submits a servicing PR that modifies a package that depends on another OOB package that had its version bumped the previous month, the CI will start showing a failure in AllConfigurations stating that the nuget dependency is not found in nuget.org.

This happens because the nuget packages created the previous month have not yet been pushed to nuget (this is expected) due to the previous month's GA date (which is the day we push them) happening after the current month's Code Complete date.

The problem gets worse if we end up merging such PR, because now the failure propagates to the servicing rolling builds and subsequent PRs.

Here is an example: #81914

To prevent this problem in the future, we have decided to separate branding from resetting the property. Here are two tasks to achieve this:

• We will write a GitHub action to automatically create a PR that finds all the csproj files under src/libraries that belong to OOB packages, and change <GeneratePackageOnBuild> to false.
• We will trigger such GitHub action at the same time as the branding PRs are created. We would like to modify the branding scripts created by @vseanreesermsft to achieve this.

These PRs would be the last ones we would merge on the Code Complete day. We will also be able to consider the official closing of the servicing branches for that month. Doing this will prevent having the servicing rolling builds and the PR CI runs in red due to nuget failures. Note: we might have some servicing rolling builds failing, but once the nuget packages get pushed, they should go away. Additionally, we will request the possibility of aligning the GA and Code Complete dates, to prevent red builds completely.

Fail when a Microsoft.Windows.Compatibility dependency is modified

The M.W.C. package is a package with no source code that depends on a bunch of other packages. If a new version of one of its dependencies gets built, we need to make sure to also build a new version of M.W.C., and push both new packages to nuget. We currently don't have an easy way to remind ourselves to do this, and it has already happened in the past that we forget to build M.W.C. and we only hear about it after a customer asks for the update.

To prevent forgetting, we have decided to take some steps:

• Implement the validation target proposed in Consider shipping Microsoft.Windows.Compatibility with every servicing release #77557 by @ericstj, which would emit a build error when a package that M.W.C. depends on gets the <GeneratePackageOnBuild> property set to true, but M.W.C. itself does not.
• Improve the documentation of M.W.C. in 6.0, 7.0 and main, to describe in more detail the need to set the property to true for M.W.C. if a dependency is built.
  • 6.0: [release/6.0] Improve servicing docs for Microsoft.Windows.Compatibility #81800
  • 7.0
  • main
• Create a dependabot task that takes care of updating the versions of the M.W.C. external dependencies in Versions props when they change.

Author:	carlossanlop
Assignees:	carlossanlop
Labels:	area-Infrastructure-libraries
Milestone:	8.0.0

[ViktorHofer]

Closing as M.W.C was moved to windowsdesktop and we started using different branches for servicing.