Co-authored-by: Marc Paine <marcpop@microsoft.com>
Co-authored-by: Elinor Fung <elfung@microsoft.com>
Co-authored-by: Přemek Vysoký <premek.vysoky@microsoft.com>
Co-authored-by: Jason Zhai <v-wuzhai@microsoft.com>
The `Build.SourceBranchName` only gets the last segment, so for `release/8.0.xxx-preview1` it was `8.0.xxx-preview1` and the branch didn't get synchronized into the VMR.
For PRs, the Source-Build leg that was running inside of the Build stage is now moved to a separate stage but runs more or less the same: https://dev.azure.com/dnceng-public/public/_build/results?buildId=97509&view=results
Instead of creating the tarball, we are building the `dotnet/dotnet` repo there.
For internal rolling builds, we are taking [this pipeline](https://dev.azure.com/dnceng/internal/_build/results?buildId=2056327&view=results) and merging it into `dotnet-installer-official-ci`.
So it's one extra stage that runs pretty quick (faster than the Build stage by far).
It won't be creating and pushing the tarball artifact anymore though.
Once the rolling build is finished, there won't be no more source-build-build pipeline but instead dotnet-dotnet-official-ci which will build the dotnet/dotnet repo again instead of the tarball that was originally produced from the rolling build.
The MSFT SDK from the installer build will still be consumed by it though.
More details https://github.com/dotnet/arcade/issues/10677
Adds a new pipeline that will run during installer's PRs that verifies that the current VMR tooling can synchronize that particular change into the VMR.
