Import the Microsoft.Dotnet.Build.Bundle package #541
Conversation
Package Microsoft.DotNet.Build.Bundle as a tool similar to ILLink.Tasks so that it can be consumed by the ToolSet repo. (dotnet/toolset#541) Packaging the bundler as a lib causes version compatibility check failures.
Package Microsoft.DotNet.Build.Bundle as a tool similar to ILLink.Tasks so that it can be consumed by the ToolSet repo. (dotnet/toolset#541) Packaging the bundler as a lib causes version compatibility check failures.
|
@dotnet-bot test this please |
|
/cc @nguerrera This is to import the bundler tool package, so that an app developer can publish single file apps (sdk changes to invoke the tool will be merged later) @nguerrera or @sbomer could one of you give some pointers to @swaroop-sridhar on how to fix the build error? This should be very similar to the ILLinker package that I imported a week ago (#501), which is also compiled for netcoreapp2.0. |
|
@livarcocc I've added the notes about bundler to the PR comments, and the checkin message; thanks. |
|
@fadimounir I spoke to @nguerrera yesterday, and figured the original problem. The issue was that the bundler should be published as a tool (similar to other tools in the toolset) to circumvent the version check. This should make the build progress, I'll watch for further errors. |
|
@dotnet-bot test this please |
|
Is there a way to re-run the failing legs in CI? |
|
Looks like the |
|
@MattGal Has the issue with retrieving packages for debian 8 (http://httpredir.debian.org jessie-updates/main amd64 Packages) been seen elsewhere? |
| @@ -11,5 +11,6 @@ | |||
| <BundledSdk Include="FSharp.NET.Sdk" Version="1.0.4-bundled-0100" /> | |||
| <BundledSdk Include="Microsoft.Docker.Sdk" Version="1.1.0" /> | |||
| <BundledSdk Include="ILLink.Tasks" Version="$(ILLinkTasksPackageVersion)" /> | |||
| <BundledSdk Include="Microsoft.DotNet.Build.Bundle" Version="$(MicrosoftDotnetBuildBundlePackageVersion)" /> | |||
There was a problem hiding this comment.
Seeing this next to the other Microsoft.NET.* has me thinking we should strong consider Microsoft.NET here instead of Microsoft.DotNet.
There was a problem hiding this comment.
@nguerrera I named the package as Microsoft.DotNet.Build.Bundle similar to Microsoft.DotNet.PlatformAbstractions in the core-setup repo.
I'm happy to change the name to Microsoft.NET.Build.Bundle if you think that's better.
CC: @KathleenDollard for package naming convention.
There was a problem hiding this comment.
@terrajobst can you please comment about this issue about package naming convention? Thanks.
There was a problem hiding this comment.
Just to be clear, this name isn't really customer facing, but it's just that I think the folder name should match its siblings.
We don't have to block the initial insertion on this.
There was a problem hiding this comment.
I don't think we ever created an official guideline. Let me start a mail thread so we close on this.
There was a problem hiding this comment.
We don't have to block the initial insertion on this.
Thanks @nguerrera. I agree. But we're blocked on the failing test leg nevertheless.
|
@nguerrera yes, actually; @ChadNedzlek was talking about hitting this yesterday with regards to us setting up VMs. I haven't had a chance to personally investigate, but I will try to see if there's evidence of why this might have changed |
|
@MattGal pranav mentioned this stackoverflow thread on a separate PR on this repo: https://stackoverflow.com/a/55358545. This is happening across all our repos and CI. Debian has been failing consistently in this way. |
|
@livarcocc , @nguerrera I am experimenting with the latest Azure gallery image to see if they've moved the location of their feeds. If that works, we can derive the proper package feed from there; otherwise it's time to talk to someone in Credative |
|
From what I can tell, the Debian managed servers for package feeds for Debian 8 seem to have just... disappeared... It's the feed that the Azure images are targeting by default. We haven't gone out of our way to pick some alternate feeds. This has happened before, and they eventually come back after a few days, but in the meantime, there isn't much we can do. We're investigating newer images to see if they point to a different feed. |
|
Stack overflow links to this tweet: https://twitter.com/debian/status/1109080168318926851?s=12 Seems they removed these by design from mirrors? |
|
So that links to a place where they say LTS architectures are staying and this is amd64 which is one of those. But https://wiki.debian.org/StableUpdates says this:
|
|
Looks like the docker images are getting updated too: debuerreotype/docker-debian-artifacts#66 |
|
Should we disable Debian 8 legs? |
|
I chatted with @MichaelSimons who says:
... so it's up to you whether to ignore or disable; with luck we should have fixed docker images by today or tomorrow. |
Package Microsoft.DotNet.Build.Bundle as a tool similar to ILLink.Tasks so that it can be consumed by the ToolSet repo. (dotnet/toolset#541) Packaging the bundler as a lib causes version compatibility check failures. Commit migrated from dotnet/core-setup@142a83f
This change adds the single-file bundler to the .Net core toolset.
The bundler is a tool that packs an app, its dependencies, the host and
optionally the runtime into a single executable file, for ease of distribution.
The Bundle tool will be invoked form the SDK, as part of dotnet CLI.
(dotnet publish /p:PublishSingleFile=true)
Further details about single-file publishing can be here:
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md