Update CoreClr, CoreFx, CoreSetup, External, ProjectNTfs, ProjectNTfsTestILC, Standard to preview1-25321-03, preview1-25322-02, preview1-25321-02, beta-25322-00, beta-25322-00, beta-25322-00, preview1-25322-01, respectively (master)#20025
Conversation
4168372 to
6feda2e
Compare
| <CoreFxExpectedPrerelease>preview2-25319-04</CoreFxExpectedPrerelease> | ||
| <CoreClrExpectedPrerelease>preview2-25316-03</CoreClrExpectedPrerelease> | ||
| <CoreFxExpectedPrerelease>preview1-25320-01</CoreFxExpectedPrerelease> | ||
| <CoreClrExpectedPrerelease>preview1-25319-05</CoreClrExpectedPrerelease> |
There was a problem hiding this comment.
master is building for 2.1.0 now, so the prerelease spec is reset to preview1. It's clearer in the full package version upgrade: 2.0.0-preview2-25319-02 -> 2.1.0-preview1-25320-02.
There was a problem hiding this comment.
Thanks, @dagood. Do you know why the build is failing? It seems to be missing something for corelib that was previously there.
There was a problem hiding this comment.
The CoreCLR it's trying to insert is missing https://github.com/dotnet/coreclr/pull/11355/files
There was a problem hiding this comment.
I don't know why this is happening, but I don't see any infrastructural reason for it. @weshaggard @gkhanna79
There was a problem hiding this comment.
That PR was merged 19 days ago - a fundamental issue with the change should have come up earlier. Have we looked into where is the ApiCompat tool looking for the API? In SPC.dll or some library built in CoreFX?
There was a problem hiding this comment.
See my fix with 444ea73. The issue was we were downgrading the package minor version so it was picking an older runtime package without these changes.
6feda2e to
a7d1600
Compare
a7d1600 to
fe7a314
Compare
fe7a314 to
edde868
Compare
edde868 to
f4ddf12
Compare
f4ddf12 to
f03674c
Compare
f03674c to
759856f
Compare
759856f to
78fb7ac
Compare
78fb7ac to
61698c2
Compare
61698c2 to
e7c6b4a
Compare
e7c6b4a to
6e63b61
Compare
6e63b61 to
ec4692e
Compare
…TestILC, Standard to preview1-25321-03, preview1-25322-02, preview1-25321-02, beta-25322-00, beta-25322-00, beta-25322-00, preview1-25322-01, respectively
ec4692e to
544b07a
Compare
|
Pulling down to build and looking into this. |
Instead of only looking at the prerelease we also now get the full package version during our update to avoid issues when major/minor/patch version change
|
Getting a number of OverflowExcptions thrown only on the windows release build https://ci.dot.net/job/dotnet_corefx/job/master/job/windows_nt_release_prtest/8250/#showFailuresLink, going to kick the build again to see if there was some transient issue. @dotnet-bot test Innerloop Windows_NT Release x64 Build and Test please |
|
Same set of overflowexception test failures. @jkotas @stephentoub are you guys aware of any coreclr changes that might impact these? |
| </PackageReference> | ||
| <PackageReference Include="runtime.native.System.Data.SqlClient.sni"> | ||
| <Version>4.4.0-$(CoreFxExpectedPrerelease)</Version> | ||
| <Version>$(PackageVersion)-$(CoreFxExpectedPrerelease)</Version> |
There was a problem hiding this comment.
You should be able to get this full version from the CoreFX build-info rather than assembling it here.
There was a problem hiding this comment.
Yes I started to do that but then I noticed we have multiple sni versions we care about one is this one and one is the RID specific packages so instead of adding yet another SNIVersion into dependencies.props I went this route. However I don't really care for this approach much either so we should consider changing that later. For now this part of the PR is unblocked, just need to figure out the test failures now.
There was a problem hiding this comment.
Agreed, unblocked. There's also an active question of whether this identity package should be created during the SNI build instead (https://github.com/dotnet/corefx/issues/16918), so wiring up another property for this might not be worthwhile.
|
Couldn't update this pull request: Head commit author 'Wes Haggard' is not 'dotnet-bot' |
|
Couldn't update this pull request: Head commit author 'Wes Haggard' is not 'dotnet-bot' |
It is likely a JIT codegen regression. Number of JIT changes went in last few days. @dotnet/jit-contrib Could you please take a look? |
|
Couldn't update this pull request: Head commit author 'Wes Haggard' is not 'dotnet-bot' |
|
Couldn't update this pull request: Head commit author 'Wes Haggard' is not 'dotnet-bot' |
|
@jkotas this does look like it could be a JIT issue: I can repro the failures in the Decimal tests by simply replacing the JIT in the current test layout with a JIT built at the current sources and setting ZapDisable to 1. Binary searching now. |
|
I've narrowed this down to the changes that came in with dotnet/coreclr#10453. @JosephTremoulet, can you take a look? |
|
Couldn't update this pull request: Head commit author 'Wes Haggard' is not 'dotnet-bot' |
|
Couldn't update this pull request: Head commit author 'Wes Haggard' is not 'dotnet-bot' |
|
Couldn't update this pull request: Head commit author 'Wes Haggard' is not 'dotnet-bot' |
|
@weshaggard, should we close this? With your commit, dotnet-bot can't update this, so we won't be able to get an updated CoreCLR with the fix when there is one. |
|
Couldn't update this pull request: Head commit author 'Wes Haggard' is not 'dotnet-bot' |
1 similar comment
|
Couldn't update this pull request: Head commit author 'Wes Haggard' is not 'dotnet-bot' |
|
Couldn't update this pull request: Head commit author 'Wes Haggard' is not 'dotnet-bot' |
Fair point. I will push just my changes a change that undoes the CoreCLR update but keeps the rest of my changes which should make this PR green so we can merge and then the next update should be able to run smoothly. |
|
Pushed an update, hopefully it should be green and when it is we should merge these changes and the let the next auto-update pick-up from their. |
|
Thanks, @weshaggard. Sounds good. |
|
System.Net.HttpListener tests appear to have hung again. Everything else completed. https://github.com/dotnet/corefx/issues/20246 |
No description provided.