Flow internal transport packages during servicing #75969
Conversation
This makes sure that partner repositories have their internal transport packages available. This needs to be set explicitly as during servicing, libraries only publish on demand. This also fixes broken 7.0 servicing builds which require at least one package to be published. Manual, partial backport of c5a20f9.
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsThis makes sure that partner repositories have their internal transport packages available. This needs to be set explicitly as during servicing, libraries only publish on demand. This also fixes broken 7.0 servicing builds which require at least one package to be published. Manual, partial backport of c5a20f9.
|
There was a problem hiding this comment.
Assuming the change works, signing off.
Questions:
- Why does this PR not contain any of the changes for eng/Versions.props that the 6.0 commit introduced? Specifically, the ProjectServicingConfiguration PatchVersion bump.
- I suspect the ProductVersion/PatchVersion/PreReleaseVersionLabel/PreReleaseVersionIteration don't make sense in this PR because it's targeting main, correct? We would probably do it when backporting.
- Left a couple other questions in the files.
| </PropertyGroup> | ||
|
|
||
| <!-- Always generate this package during servicing to flow the dependency to WindowsDesktop. --> | ||
| <PropertyGroup Condition="'$(PreReleaseVersionLabel)' == 'servicing'"> |
There was a problem hiding this comment.
Why does this PropertyGroup and the one from the file above contain the condition for 'servicing', but not the 6.0 change? Back then, this condition was part of the packaging.targets file.
There was a problem hiding this comment.
Because the 6.0 change was directly committed to release/6.0 when release/6.0 meant 6.0.1. That branch will never again mean anything else than servicing, that's why the condition wasn't needed. This change is more universal and works in both servicing, RTM and main.
| <GeneratePackageOnBuild Condition="'$(GeneratePackageOnBuild)' != 'true'">false</GeneratePackageOnBuild> | ||
| <!-- When in source-build we need to generate all packages when building for all configurations even in servicing. --> | ||
| <GeneratePackageOnBuild Condition="!$(GeneratePackageOnBuild) and | ||
| <GeneratePackageOnBuild Condition="'$(GeneratePackageOnBuild)' != 'true' and |
There was a problem hiding this comment.
Comparing to the 6.0 commit, I see the conditions are very different now.
- Added: GeneratePackageOnBuild != true
- Added: IsRIDSpecificProject != true
- Removed: PreReleaseVersionLabel == servicing
- Removed: GitHubRepositoryName != runtimelab
- Changed: BuildAllConfigurations != true to == true
- Added: DotNetBuildFromSource == true
For my own education, would you mind explaining all these differences?
There was a problem hiding this comment.
Those conditions were "cleaned-up" in an unrelated change. This change just uses a different style for the condition: instead of !$(GeneratePackageOnBuild) it now uses '$(GeneratePackageOnBuild)' != 'true' which is the syntax that I prefer. Mainly because it also works when the property isn't set.
ProjectServicingConfiguration was a configuration for the legacy part of the Microsoft.DotNet.SharedFramework.Sdk infrastructure that meanwhile got removed.
Correct. Those changes will happen when we brand release/7.0 to 7.0.1. |
|
/backport to release/7.0 |
|
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3099897650 |
This makes sure that partner repositories have their internal transport packages available. This needs to be set explicitly as during servicing, libraries only publish on demand.
This also fixes broken 7.0 servicing builds which require at least one package to be published.
Manual, partial backport of c5a20f9.
This change will be backported into release/7.0 after it is merged.