Prefer OutputRid over PackageRID for output artifacts.#76871
Prefer OutputRid over PackageRID for output artifacts.#76871ViktorHofer merged 3 commits intodotnet:mainfrom
Conversation
This is a non-functional change that makes it more visible these are output artifacts.
ghost
added
area-Infrastructure-libraries
community-contribution
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsThis is a non-functional change that makes it more visible these are output artifacts. @ViktorHofer @am11 ptal.
|
|
I was triggered to make this change because I'd rather see
CI should take a look first to verify I didn't break anything. |
src/libraries/System.Net.Http/tests/StressTests/HttpStress/Directory.Build.props
Show resolved
Hide resolved
src/libraries/System.Net.Security/tests/StressTests/SslStress/Directory.Build.props
Show resolved
Hide resolved
| Condition="'$(BuildTargetFramework)' == '$(NetCoreAppCurrent)' or '$(BuildTargetFramework)' == ''"> | ||
| <GenerateFileVersionProps Files="@(SharedFrameworkRuntimeFile)" | ||
| PackageId="$(MicrosoftNetCoreAppFrameworkName).Runtime.$(PackageRID)" | ||
| PackageId="$(MicrosoftNetCoreAppFrameworkName).Runtime.$(OutputRid)" |
There was a problem hiding this comment.
This changes the non-shipping "fake" runtime pack id. Do we also make changes to the actual shipping runtime pack sfxproj? I'm suprised that there aren't any changes to the sfxprojs.
There was a problem hiding this comment.
I wasn't aware there's a fake runtime pack id, and a shipping runtime pack id.
Do these represent different builds?
I assume the sfxprojs pick up the MicrosoftNetCoreAppRuntimePack* properties?
There was a problem hiding this comment.
No, both use the same assets underneath but the composition of them is different (predates the repository consolidation).
I assume the sfxprojs pick up the MicrosoftNetCoreAppRuntimePack* properties?
Unsure about that. Please double check. You should be able to build the sfxprojs via the packs subset.
|
CI doesn't look happy. There seem to be many NuGet issues. |
|
CI is looking much better. There are 2 jobs that have timed out. @ViktorHofer do you want to retrigger those, or run the whole thing? I'm not sure what I should validate for #76871 (comment). Is green CI enough? Can we trigger CI also for the unknown Banana rid? Azure shows it greyed out, so I think it doesn't run by default. |
|
ping @ViktorHofer |
|
@ViktorHofer can you take a look? |
|
We need to retrigger CI as the previous build isn't available anymore. |
|
/azp run runtime |
|
/azp run runtime-dev-innerloop |
|
/azp run runtime-staging |
|
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run dotnet-linker-tests |
|
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
The unsuccessful jobs failed in the 'Send to Helix' step. I don't see any build or test failures related to the PR changes. |
|
Sorry that it took me longer to reply. Looking into this comment right now:
Need to figure out where the RID is encoded and how to trigger it. |
|
I couldn't find a good way to trigger the banana rid as it had a condition on it to only run for rolling builds. I just removed that condition to get CI validation. We can revert my commit before merging. |
|
The banana rid build passed: https://dev.azure.com/dnceng-public/public/_build/results?buildId=80118&view=logs&j=98fdc254-13b3-5066-1dc8-532bea57cf83. Other CI jobs look good too. I removed the commit that triggered the banana rid job. This should be good to merge. |
|
Thanks @tmds |
ghost
locked as resolved and limited conversation to collaborators
2 participants
This is a non-functional change that makes it more visible these are output artifacts.
@ViktorHofer @am11 ptal.