Dev branch README instructions currently don't seem to get latest CoreCLR bits

[JosephTremoulet]

I'm seeing some behavior I can't explain, don't know which part if any is wrong or if I'm just misunderstanding something.

I thought the dev branch should always be running against "the latest" CoreCLR bits, and that doesn't seem to be the case today, but maybe there is no "the" latest?

Anyway, if I follow the steps in the readme today, after running the two dotnet-install.ps1 commands, dotnet --info gives me this:

.NET Command Line Tools (2.1.0-preview1-007214)

Product Information:
 Version:            2.1.0-preview1-007214
 Commit SHA-1 hash:  2956c548b9

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   D:\Source\JitBench\.dotnet\sdk\2.1.0-preview1-007214\

Microsoft .NET Core Shared Framework Host

  Version  : 2.1.0-preview2-25616-02
  Build    : 8aa34a95bad481e1b5e4c8286e5cb2d7cb6ed943

As I understand it, the 2.1.0-preview2-25616-02 there means this corresponds to https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.App/2.1.0-preview2-25616-02

Question 1: Why is that getting 2.1.0-preview2-25616-02 when 2.1.0-preview2-25711-01 is available?

At any rate, the info page for that nuget package/version (NetCoreApp 2.1.0-preview2-25616-02) repeats the 8aa34a95bad481e1b5e4c8286e5cb2d7cb6ed943 hash that matches the "Build" line of the dotnet --info output; presumably this corresponds to commit dotnet/core-setup@8aa34a9. Browsing the core-setup files at that commit, dependencies.props points to CoreCLR runtime package version 2.1.0-preview2-25610-02.

This in turn presumably refers to https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.Runtime.CoreCLR/2.1.0-preview2-25610-02, which references dc2ffcdff2fb19e4b252cec3bc6672400a375c1e , which presumably is commit dotnet/coreclr@dc2ffcd, a commit from August 10.

Following the same chain from the latest preview2 version of Microsoft.NETCore.App (https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.App/2.1.0-preview2-25711-01), it seems to point to dotnet/core-setup@4cd37c5, where dependencies.props points to CoreCLR runtime package version 2.1.0-preview2-25707-02, which references dotnet/coreclr@49676af, a commit from September 6.

So, even assuming that we want preview2 bits, I don't understand why we're getting the August 10 bits instead of the September 6 bits.

But even September 6 was a while ago. I notice that Microsoft.NETCore.App package version 2.1.0-preview1-25719-04 has a newer date, and indeed following the trail through dotnet/core-setup@b5c917c via dependency.props to Microsoft.NETCore.Runtime.CoreCLR package version 2.1.0-preview1-25718-02, it references commit dotnet/coreclr@cd6b92a, which is a commit from September 16.

What's more, core-setup's current master branch's dependencies.props references a "preview1" version, not a "preview2" version, and there hasn't been a new "preview2" package since September 11, so I don't know if "preview2" got dropped or is in some branch/"channel" other than "master" or what...

Should something in the readme steps or the package generation/publishing be different such that we could be running against the September 16 CoreCLR bits instead?

[JosephTremoulet]

/cc @rynowak @eerhardt

[eerhardt]

Question 1: Why is that getting 2.1.0-preview2-25616-02 when 2.1.0-preview2-25711-01 is available?

There were a bunch of bugs/breaks/etc in dotnet/coreclr that blocked taking new runtime builds into the dotnet/cli repo. That build of dotnet/cli was still using 25616-02. If you want more info on the breaks, see dotnet/cli#7606.
The latest CLI build has 2.1.0-preview1-25719-04 of the runtime.

so I don't know if "preview2" got dropped or is in some branch/"channel" other than "master" or what...

Yes, there was a change from "preview1" to "preview2" in the master branches at the end of June. Then later, it was reverted to go back to "preview1". So the latest .NET Core 2.1 runtimes are "preview1". /cc @weshaggard

[rynowak]

Ugh... trying to time travel back to 1955 with versions causes all kinds of havoc. If you went back in time, is the right thing to do to purge all of the 'preview2' builds from the feed?

Basically my guess is that latest is pulling in a preview2 build, I'm not familiar with the details of how this works. Is there a workaround? Does this require cleanup on your side?

[JosephTremoulet]

That build of dotnet/cli was still using 25616-02

Ok... but why was I using that build of dotnet/cli? I just used the Dotnet-Install.ps1 script, like so:

Dotnet-Install.ps1 -SharedRuntime -InstallDir $InstallDir -Channel master -Architecture x64  # implicit "-Version latest" here
Dotnet-Install.ps1 -InstallDir $InstallDir -Channel master -Architecture x64

and then apparently that's the build of dotnet/cli that was getting installed. If I switch to invoking Dotnet-Install.ps1 like so:

Dotnet-Install.ps1 -SharedRuntime -InstallDir $InstallDir -Channel master -Version 2.1.0-preview1-25719-04 -Architecture x64
Dotnet-Install.ps1 -InstallDir $InstallDir -Channel master -Architecture x64

then I get a different, newer, still "preview1", cli version:

.NET Command Line Tools (2.1.0-preview1-007228)

Product Information:
 Version:            2.1.0-preview1-007228
 Commit SHA-1 hash:  28a1f7e9d6

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   D:\path\.dotnet\sdk\2.1.0-preview1-007228\

Microsoft .NET Core Shared Framework Host

  Version  : 2.1.0-preview1-25719-04
  Build    : b5c917c0b24171ae27c7cfcfd2617b1088d41c11

my guess is that latest is pulling in a preview2 build

That seems to be what I'm seeing, yes.

[eerhardt]

Dotnet-Install.ps1 -SharedRuntime -InstallDir $InstallDir -Channel master -Architecture x64  # implicit "-Version latest" here
Dotnet-Install.ps1 -InstallDir $InstallDir -Channel master -Architecture x64

There are 2 calls to Dotnet-Install.ps1 here. The first one is installing the latest runtime (that's what the -SharedRuntime option does). The second one is installing the latest SDK AND the runtime that comes with it.

So only the last line is actually installing an SDK. And you aren't changing any options on that line. However, the thing that is changing is time. Depending on the time you call Dotnet-Install.ps1 -Channel master, you will get different versions. It installs the latest build in that channel.

Looking at https://github.com/dotnet/versions/commits/master/build-info/dotnet/cli/master

You will see there was a new SDK build produced 3 hours ago (right around the time this issue was created, so I assume you ran that command greater than 3 hours ago). Before that last version, it had been 9 days since the last SDK official build was complete.

[JosephTremoulet]

Ok, I'm starting to get it, thanks. So then if I'm following correctly:

• The dotnet-install tooling does seem to correctly identify the newer "preview1" versions as newer than the "preview2" versions (hooray!)
• The myget.org feed view seems to incorrectly list the "preview2" versions above the "preview1" versions, and even goes so far as to mark the newest "preview2" version as the "Recommended release"; it was my mistake to think the dotnet-install tooling was taking the same view
• The latest published dotnet/cli package feed happened to be wedged at a "preview2" version of NetCoreApp, and only got unstuck this morning
• The CoreCLR runtime package feed and NetCoreApp package feed had both progressed from "preview2" back to "preview1" while the dotnet/cli package feed was wedged

So then there's nothing to fix and I'll close this issue, but I do still have a question: Sometimes I'm in the situation where a change has gone into CoreCLR and I want to know when it will be available in these daily preview feeds. My practice had been to watch the runtime package feed for a build containing the change, and then watch the NetCoreApp package feed for a build containing that runtime package, and find a relevant PR in the dotnet-setup repo to figure out what issues might be preventing the new runtime package from being picked up. It seems I was missing a step of watching to see when a new cli build was published that picked up the new NetCoreApp package -- where would be the right place to go to see whether that's happened and see what issues are blocking it if it hasn't happened yet? @eerhardt, I see you've linked to https://github.com/dotnet/versions/commits/master/build-info/dotnet/cli/master, but I think I'm still missing a step to connect the dots to which version of NetCoreApp is included in the latest build.

[JosephTremoulet]

(to be clear, when I go back now and re-run the steps as they are in the README [to pick up "latest"], I get a recent "preview1" version of NetCoreApp/CoreCLR_runtime)

[rynowak]

So then there's nothing to fix and I'll close this issue, but I do still have a question

If you and @eerhardt come up with a better idea of how to consume bits rapidly I'm happy to update what we have here to support it, or document the workflow as part of this repo's instructions. I'm using the dotnet-install scripts provided by the CLI team because that's the closest we have to 'supported' right now without requiring an additional dependency

[eerhardt]

Currently there are multiple stages of committing a change in CoreCLR and seeing it in the SDK. We are working on making this faster/better (by building the repos together), but what we currently have is a staged flow of dependencies.

CoreCLR and CoreFX repos produce a build. The outputs of those repos go into the dotnet/core-setup repo. This is what produces the Microsoft.NETCore.App package and the "shared framework". When a new "shared framework" is produced, the version flows into the dotnet/cli repo. The way each of these repos are updated are through web hooks on the https://github.com/dotnet/versions repo. At the end of the upstream repo's build, it writes a build-info file to this repo, which kicks off a webhook. The webhook submits a PR to the downstream repo to update to the latest version.

You can see these PRs:

https://github.com/dotnet/core-setup/pulls/dotnet-maestro-bot
https://github.com/dotnet/cli/pulls?q=is%3Apr+author%3Adotnet-bot+is%3Aclosed

They take the form "Update UPSTREAM to XYZ (branch)".

So things that can slow the flow down are:

• upstream repos (corefx, coreclr, core-setup) official builds being broken
• the PR into downstream repos being broken (usually because of bugs/breaking changes shipped by upstream repos)
• the downstream repos official builds being broken

All of these things have happened in the last month multiple times, which has really slowed down the flow of changes from bottom to top.

come up with a better idea of how to consume bits rapidly

I think what you have now is enough - you can independently take new "shared frameworks" without the SDK updating to it. When this new build infrastructure comes, the flow should be faster.

[rynowak]

I think what you have now is enough - you can independently take new "shared frameworks" without the SDK updating to it. When this new build infrastructure comes, the flow should be faster.

So I guess since we acquire the CoreCLR via the shared framework via dotnet-install, in theory the only things gating us using a new CoreCLR build are a break in:

• CoreCLR (duh)
• CoreFx
• Core-Setup

---

As an aside, I think it would be cool to produce a global tool that understands the dotnet/versions repo for this sort of thing once we have that ability to build global tools. I would really like to use that as the source of truth, but that would require an external dependency right now with no way to bootstrap it.

[eerhardt]

the only things gating us using a new CoreCLR build are a break in

Core-setup updates its CoreCLR independently of CoreFX. They can come together or separate. So technically, you can cut CoreFX from that list.

a global tool that understands the dotnet/versions repo

We have the basis of a library that understands how to read/write to the dotnet/versions repo: https://github.com/dotnet/buildtools/tree/master/src/Microsoft.DotNet.VersionTools. You can get that library as a standalone NuGet package https://dotnet.myget.org/feed/dotnet-buildtools/package/nuget/Microsoft.DotNet.VersionTools

[JosephTremoulet]

So it looks like the most recent PR from (upstream) core-setup into (downstream) cli was dotnet/cli#7606, which was merged a week ago. But running the script yesterday didn't fetch the new bits, so presumably the official builds in the cli repo were broken this past week, only resolved a few hours ago? I think what I'm still missing is how I would have known that step was stalled (simply that https://github.com/dotnet/versions/commits/master/build-info/dotnet/cli/master didn't yet have an "Updating build-info/dotnet/cli/master for preview*" commit yet?) and what it was waiting on, is that sort of information available somewhere?

[rynowak]

I think what I'm still missing is how I would have known that step was stalled (simply that https://github.com/dotnet/versions/commits/master/build-info/dotnet/cli/master didn't yet have an "Updating build-info/dotnet/cli/master for preview*" commit yet?) and what it was waiting on, is that sort of information available somewhere?

To me that's the kind of thing that I'd want to output from a tool like this. It's cool that you guys have a library already maybe I'll take a stab at it.

[eerhardt]

We've had some infrastructure issues that have been blocking daily builds, but we have been getting them going again yesterday and today.