Add portable linux source build leg #75546
Conversation
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos. While doing this, I cleaned up a couple parameters to make it clearer what they were doing
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
ghost
assigned 
mmitche
requested review from
MichaelSimons,
hoyosjs,
jkoritzinsky and
ViktorHofer
|
Artifacts looked good except for the logs. Those had overlapping artifact names. Fixed that. https://dev.azure.com/dnceng/internal/_build/results?buildId=1991830&view=results |
|
Getting closer here. Latest build looks correct except the publishing asset manifests need to have different names. |
|
Depends on dotnet/arcade#10860 |
|
Depends on #75929 to add the right parameter to the common YAML step template. |
|
Updated arcade to get ahead on validation, and this should be the final official build test: https://dev.azure.com/dnceng/internal/_build/results?buildId=1999350&view=results |
|
@tmds @MichaelSimons I ended up reverting the change to use the banana RID here: bf026ca. I don't think this was correct, as it meant that runtime's official build was only producing source-build intermediates for the banana rid, which means that downstream repos could not actually consume these in their source-build legs. I think the intention was to test a banana.blah RID (built on whatever container). if that's the case, maybe it makes sense to introduce an additional CI or PR (if it breaks enough) leg to validate these scenarios. But the official builds need to produce a real RID. |
|
Yes, the goal is to verify you can build for an unknown rid. This requires All other CI jobs use known rids, and in most cases the rid being restored is even the same as the one being built (like We should continue to have a CI job that builds an unknown rid, otherwise these mix-ups go undetected until they break source-build. |
| - template: /eng/common/templates/steps/source-build.yml | ||
| parameters: | ||
| platform: | ||
| buildScript: $(_sclEnableCommand) $(Build.SourcesDirectory)$(dir)build$(scriptExt) | ||
| nonPortable: true | ||
| # Use a custom RID that isn't in the RID graph here to validate we don't break the usage of custom rids that aren't in the graph. | ||
| targetRID: banana.24-x64 |
There was a problem hiding this comment.
You remove the custom RID, but we want to keep it to make sure that we can build with arbitrary RIDs.
There was a problem hiding this comment.
Then we probably need another leg, or one that only runs in PRs? Preference?
There was a problem hiding this comment.
@ViktorHofer @tmds @MichaelSimons I made some tweaks:
- Build only linux-x64 portable officially (nothing else flows)
- Add missing PR legs for linux-x64 (to avoid official breaks)
- Add rolling CI for Banana and centos7
- Run centos.7 and banana.24 in rolling CI - Run linux-x64 in PR
|
Outputs looking good. Any additional comments? |
Adds a portable linux source build leg to the official build. The idea is that these packages produced by this build should be relied upon in downstream PR validation, rather than the RID specific assets. This should allow for cleaner SB logic in downstream repos.
While doing this, I cleaned up a couple parameters to make it clearer what they were doing