6.0 source-build servicing builds are not producing all runtime libs/packages

[MichaelSimons]

For Microsoft servicing builds (e.g. 6.0.1), only the libraries that have servicing changes are built/released. The remainder of the libraries do not get built/released. This does not work for source-builds as they are required to produce the entire product. To achieve this pre-6.0 it looks like the BuildAllPackages, BuildAllOOBPackages and StabilizePackageVersion properties were utilized to build all of the libraries. The two BuildAllPackages properties appear to have been removed in 6.0. How should the runtime source-build be configured to produce all of the libraries for servicing builds?

This was discovered post 6.0.1 release. The 6.0.1 release "worked" because any of the non-built libs were picked up from the previously source-built artifacts which are available to source-build. When building for 6.0.2, the non-built packages are missing from the 6.0.1 output and therefore failing the build.

cc @crummel, @ericstj

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

Issue Details

---

For Microsoft servicing builds (e.g. 6.0.1), only the libraries that have servicing changes are built/released. The remainder of the libraries do not get built/released. This does not work for source-builds as they are required to produce the entire product. To achieve this pre-6.0 it looks like the BuildAllPackages, BuildAllOOBPackages and StabilizePackageVersion properties were utilized to build all of the libraries. The two BuildAllPackages properties appear to have been removed in 6.0. How should the runtime source-build be configured to produce all of the libraries for servicing builds?

This was discovered post 6.0.1 release. The 6.0.1 release "worked" because any of the non-built libs were picked up from the previously source-built artifacts which are available to source-build. When building for 6.0.2, the non-built packages are missing from the 6.0.1 output and therefore failing the build.

cc @crummel, @ericstj

Author:	MichaelSimons
Assignees:	-
Labels:	area-Infrastructure-libraries, untriaged
Milestone:	-

[ericstj]

cc @safern @eerhardt @carlossanlop

I think you need to modify this:

runtime/eng/packaging.targets

Lines 29 to 36 in 1c2501d

	<GeneratePackageOnBuild Condition="('$(BuildAllConfigurations)' == 'true' or
	'$(IsRIDSpecificProject)' == 'true') and
	'$(PreReleaseVersionLabel)' != 'servicing' and
	'$(GitHubRepositoryName)' != 'runtimelab'">true</GeneratePackageOnBuild>
	<GeneratePackageOnBuild Condition="'$(BuildAllConfigurations)' != 'true' and
	'$(IsRIDSpecificProject)' != 'true' and
	'$(PreReleaseVersionLabel)' == 'servicing' and
	'$(GitHubRepositoryName)' != 'runtimelab'">false</GeneratePackageOnBuild>

I found in c5a20f9#diff-bde310e498052e67ae73f9f1014b3ee8e067170b61c410b6b3e180fb79ed7278R27

[crummel]

Do we need to be concerned about shipping packages with unstable version numbers? The scenario I'm thinking of is:

1. Red Hat developer using the source-built SDK takes a dependency on a CoreFX package that didn't ship outside of source-build, say System.Collections.Immutable 6.0.1-servicing-12345.
2. Eventually a MSFT-built System.Collections.Immutable 6.0.1 version is released.
3. Red Hat developer shares the project with a non-Red-Hat developer using the Microsoft build.
4. Non-RHEL developer tries to restore the project but no unstable version of this package >= 6.0.1-servicing-12345 exists. Will it fall forward to the Microsoft-built 6.0.1 version? Or is it better to not match here since the source-build 6.0.1-servicing-12345 is not actually the same as the MSFT-built 6.0.1?

We could condition StabilizePackageVersion on DotNetBuildFromSource as well if this is a problem I think.

[safern]

We could just set GeneratePackageOnBuild=true when DotNetBuildFromSource=true would that be enough to solve this?

[MichaelSimons]

Do we need to be concerned about shipping packages with unstable version numbers

Unstable versions or not won't address the issue that source-build releases all libraries. If source-build consumers define their projects w/pinned versions, there will be compatibility issues with the Microsoft builds. This feels like a larger problem that we should re-open/discuss in 7.0. For 6.0 @Saferns suggestion feels sufficient.

@safern - Can you create a PR with the proposed changes for release/6.0 so that we can get source-build unblocked?