-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Use the BaseOS property as the "portable" rid for building installers #44800
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… in non-portable builds.
<BuildArgs>$(BuildArgs) /p:PortableBuild=$(PortableBuild)</BuildArgs> | ||
<BuildArgs Condition="'$(ShortStack)' != 'true' and '$(TargetOS)' != 'linux-musl'">$(BuildArgs) /p:RuntimeOS=$(RuntimeOS)</BuildArgs> | ||
<BuildArgs Condition="'$(ShortStack)' != 'true' and '$(TargetOS)' != 'linux-musl'">$(BuildArgs) /p:BaseOS=$(BaseOS)</BuildArgs> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These properties aren't respected in most of the VMR repositories (i.e. managed only repos). Do we really want to always pass them in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might make sense to introduce a new property that defines if these properties should be passed in. That would then be set in runtime.proj and aspnetcore.proj. Btw I would expect a few others to need this as well eventually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking here was to make these properties available in the same way that the Arcade SDK makes the other properties used by the Installers package are always available even if nothing uses them.
Putting the properties here also helps reduce the number of multi-repo changes we'd need to make when we inevitably forget that we need to opt-in here.
I can make it opt-in though if you prefer (and opt-in runtime, aspnetcore, SDK)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Global properties are different though... They appear in the repo build invocation and in the repo binlog as build args. Keeping the number of global properties limited is a general recommendation.
Here with an orchestrator, I understand that it doesn't matter that much but still wanted to mention it.
My next question would probably be why we even need to pass some of these in instead of calculating them in the repo itself. We eventually want to set up repo UB legs similar to the existing repo source build legs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These properties are calculating the default values for HostOS
and BaseOS
. In source-build scenarios (the only scenario where they really matter today), they'll be overridden on the command line by the orchestrator.
What do you think about moving these "default" definitions into the Arcade SDK and then only pass them here when they're explicitly provided?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that would be best. But we can for sure do that in a follow-up. Feel free to merge when ready.
Fixes dotnet/source-build#4728