Alpine end to end support checklist

[janvorli]

This issue keeps track of progress on adding end to end Alpine support. As the comment https://github.com/dotnet/coreclr/issues/917#issuecomment-344163031 shows, the transparency of what was done and what needs to be done yet was low, so this issue tries to fix that.

• Enable build of coreclr native components on Alpine
• Enable build of corefx native components on Alpine
• Enable build of core-setup native components on Alpine
• Create Alpine bootstrap CLI and upload it to Azure so that the coreclr, corefx, core-setup repos can use it for building managed components
• Enable build of coreclr managed components on Alpine
• Enable build of corefx managed components on Alpine
• Enable build of core-setup managed components on Alpine
• Enable official build of coreclr nuget packages for Alpine
• Enable official build of corefx nuget packages for Alpine
• Enable official build of core-setup nuget packages for Alpine

At this point, Alpine Linux can be targeted by CLI on non-Alpine platforms, but not much testing was done yet.

• Enable CI tests for Alpine in coreclr
• Enable CI tests for Alpine in corefx
• Enable CI tests for Alpine in core-setup
• Enable test lab runs of coreclr unit tests for Alpine
• Enable test lab runs of corefx unit tests for Alpine
• Enable test lab runs of core-setup unit tests for Alpine

Enabling test lab runs depends on the lab infrastructure adding support for Alpine containers (tracked by https://github.com/dotnet/core-eng/issues/1799)

• Fix all remaining issues exposed by the lab test runs
• Enable CLI repo building for Alpine

At this point, Alpine Linux can be targeted by CLI running directly on Alpine

[johnnyasantoss]

The issue from test labs is private and not accessible for everyone. Is that correct?

[janvorli]

@johnnyasantoss yes, that's correct. That is a private repo used by the infrastructure team.

[ghost]

Will .NET Core 2.1 be available via Apline's native package repositories https://pkgs.alpinelinux.org/packages?

[Petermarcu]

@kasper3 I think we need to solve the ability for distros to build and bootstrap .NET Core from a source tarball before it can be in the official package repositories.

[ghost]

@Petermarcu, that will be great. It seems like the current approach for distro using dotnet/source-build is:

• first build tarball for your OS, this tarball will be bound to RID
• then build .NET Core from this tarball

Typically, this means we are building from git sources and tarball is not the starting point?
It would be nice if tarball itself is a single source of truth and the RID is configurable. This will increase the tarball size a bit, but it will match the convention:

• download and build dotnet-<version>.tar.xz with your RID

that's it, regardless of which operating system it is, BSD, Linux, Mac or Windows. If someone tries to build that tar on Solaris for example, then the build time will fail as it is not tested there yet (e.g. smartOS folk is not very Clang-savvy yet, GCC is still the most trustworthy compiler in many serious unices).

The hard part will be to put all combinations of those prebuild nuget packages (or the stage0 dotnet-cli, that have dependencies on native modules.. that would require to pack all combinations of all arch, os, libc kinds... So on Alpine, the tarball gets build without glibc dependency.

[Petermarcu]

@kasper3 this would be a great conversation to have on the https://github.com/dotnet/source-build repo which is where the effort to get this all figured out is happening.

[Petermarcu]

Looks like everything on the list is done other than bug fixing functional issues. I think those can be tracked as individual issues in the product in the repo they are in. @janvorli do you agree? Do you think we can close this one now?

[janvorli]

@Petermarcu makes sense, closing this issue now.