Enable installer in VMR build #18632
Conversation
mmitche
commented
Feb 12, 2024
•
mmitche
commented
- Unified build control update
- Gather installers in VMR output
- Write out the windows desktop package version before building installer
- Rework GenerateLayout a bit to avoid duplication of some property patterns and excessive sprinkling of DotNetBuild conditions.
- Aspnetcore is still downloaded in VMR non-source-only builds
- The alternate apphost msis, generated in other builds, are also downloaded rather than pulled from the upstream runtime build.
- Do not pass an OSName override unless not building portable. If OSName is specified on windows via the repo project file, it ends up as "windows". This ends up used in the installer repo to build the names of various packages (e.g. crossgen), as well as other uses that implicitly assume that "win" is what OSName will be. This is typically because OSName is derived from the target rid.
- Don't create the internal sdk zip files (still creates the installers)
- Unified build control update - Gather installers in VMR output - Write out the windows desktop package version before building installer - Rework GenerateLayout a bit to avoid duplication of some property patterns and excessive sprinkling of DotNetBuild conditions. - Aspnetcore is still downloaded in VMR non-source-only builds - The alternate apphost msis, generated in other builds, are also downloaded rather than pulled from the upstream runtime build. - Do not pass an OSName override unless not building portable. If OSName is specified on windows via the repo project file, it ends up as "windows". This ends up used in the installer repo to build the names of various packages (e.g. crossgen), as well as other uses that implicitly assume that "win" is what OSName will be. This is typically because OSName is derived from the target rid. - Don't create the internal sdk zip files (still creates the installers)
Co-authored-by: Viktor Hofer <[email protected]>
|
That's fine. When are you planning on merging this? Have all the supporting changes been done? |
Preferably, as soon as my team gets some reviews on it. The syncing process (making sure all changes make it into my SDK repo branch) should only take a few hours. So, I'd update my PR to be synced with That PR is just cleanup/consolidation/refactoring I've done since working on this Installer -> SDK merge. It shouldn't change the way this repo currently functions, so there shouldn't be any supporting changes necessary. If there are, I'm not aware of them. I ran the branch against our public and private CI pipelines. |
|
/azp run installer-unified-build-full |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Passed, running full build to check up on osx. |
|
/azp run installer-unified-build-full |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run installer-unified-build-full |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
It looks like we're not actually passing the architectures properly.... |
|
/azp run installer-unified-build-full |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run installer-unified-build-full |
|
Azure Pipelines successfully started running 1 pipeline(s). |
mmitche
changed the title
|
/azp run installer-unified-build-full |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I think this is ready to go, as soon as @mthalman's changes go in so that I don't stomp him accidentally. The failures are present in mainline right now, and are related to the inner-command warning format change. |
