Dev branch README instructions currently don't seem to get latest CoreCLR bits about jitbench HOT 14 CLOSED

/cc @rynowak @eerhardt

from jitbench.

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

from jitbench.

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?

from jitbench.

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.

from jitbench.

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.

from jitbench.

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.

from jitbench.

(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)

from jitbench.

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

from jitbench.

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.

from jitbench.

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.

from jitbench.

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

from jitbench.

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?

from jitbench.

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.

from jitbench.

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

from jitbench.