[release/6.0] Fix for InformationalVersion #61240
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
In stable package mode we should be setting CoreLib informational version to the ProductVersion according to the discussion on the issue thread. I have verified locally that this fixes the processinfo2 test for me that was previously failing in the StabilizePackageVersion mode. Please let me know how to proceed with the fix, whether you want me to just merge it into dotnet/runtime main, whether I should pursue its backport into 6.0 release and / or whether Matt considers cherry-picking my change to his stabilization PR. Thanks Tomas
|
Tagging subscribers to this area: @hoyosjs |
|
yes tell-mode is good here. |
|
Hmm, the dotnet-linker-tests seem to be busted with the "No space left on device" infra issue; I retried them several times, not sure if there's anything else I can do right now. /cc @MattGal for visibility although I'm pretty sure he's already aware of the problem. |
Taking a look. Note that in case I take some vacation days or get sick you can tag @dotnet/dnceng as well. |
|
@trylek we're aware of this one and we're actively working to address it. Basically, it all stems from running out of AMD Epyc Cores in the data center we use, leading to moving to D_v4. These SKUs unexepectedly lack the 100 GB "extra" SSD so fill up quickly. We've moved most builds over to D_v3 cores (and hopefully can bring back some to Da_v4 soon) but to set the 1ES Pool provider to support this we have to apply for more quota. I'll work with the guys doing this to get it moved over today, but it may reduce capacity for some time. Tracking issue: https://github.com/dotnet/core-eng/issues/14830 |
|
Do we also need to backport the Mono part of the fix? #60614 |
#60572 for Mono's corelib.
Done. |
danmoseley
changed the title
|
Fixed title, it's really helpful to not just have numbers in issue/PR titles 😸 |
|
Thanks Jan and Dan for your contributions. The only downside is that the Mono runs seem quite broken right now even though I certainly can't claim it's because of the Mono SPC change (in fact it would be quite surprising). @steveisok, could you or someone from the Mono team please comment on the failures so that we know whether this change is safe to merge? |
The runtime-staging Android legs are failing due to the disk space issues from the 1ES pools. The only recourse besides merging on red is to retry. I've kicked it off again. |
|
As for the runtime ones, there appears to be some kind of infra issue w/ the runtime tests, which appears to be unrelated. The wasm failure is a known issue w/ docker. |
|
Great, thanks Steve for the detailed explanation! |
I've opened a Sev A regular support ticket for the quota increase needed to fix this for -Svc queues. They must be slammed because previously even a Sev C one got serviced same day (I now have a B I opened yesterday and an A from this morning. |
|
@trylek is this one ready to merge ? |
|
@Anipik - yes, I believe that Matt and Steve confirmed all remaining bugs are "infrastructural" or "unrelated", after all this is a pretty minimal change, but I apparently don't have the authorization to merge in without all legs passing. |
ghost
locked as resolved and limited conversation to collaborators
Backport of #60572 to release/6.0
Turns out I missed Jeff's response from two weeks back asking me to backport this change, doing that now I received a heads-up about the lingering problem.
/cc @jkotas @trylek
Customer Impact
Informational assembly version for System.Private.CoreLib includes undesirable internal build version information.
Testing
Local testing, lab testing, the change has received 2 weeks bake time in the runtime repo pipelines.
Risk
Low - informational assembly version is not used by the runtime at all, it's just a bit of extra metadata.