Comments (14)
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.
Related Issues (20)
- A new database warning HOT 1
- A new database issue on appveyor HOT 2
- Update dotnet-install scripts HOT 1
- Remove set +e from scripts that get sourced HOT 1
- Dev branch build is broken HOT 12
- dotnet store fails with error that it cannot find DiaSymReader HOT 1
- Cannot find framework... HOT 1
- Enable CI HOT 1
- All branches currently broken HOT 4
- dotnet publish failing for 2.0 x86 HOT 14
- Announcement: rel/2.0.0-preview2 available HOT 1
- Announcement: Precompilation was on by default
- JitBench dev branch not using master branch builds of CoreCLR HOT 5
- Known Issue: Unable to resolve path for 'coreclr' HOT 2
- Announcement: Updating to netcoreapp2.1 HOT 1
- Discussion: Using custom crossgen for JitBench HOT 7
- MusicStore fails with System.Net.Http.HttpRequestException error HOT 6
- Support latest 3.0 preview HOT 4
- Announcment: Updating to 3.0 and simplifying scripts
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jitbench.