Support container operations on Windows runners

[tprk77]

Describe the enhancement

I would like to run a Windows Docker container on a Windows runner. But was surprised to find out that this is not supported:

Error: Container operations are only supported on Linux runners

Specifically, I am asking that:

• jobs.<job_id>.container work on Windows runners
• It allows for use of Windows containers (as opposed to Linux containers)

Code Snippet

Here's an example workflow of what I'm asking for:

jobs:
  windows-build:
    name: Windows Build
    runs-on: windows-2019
    container:
      image: mcr.microsoft.com/windows/servercore:ltsc2019
    steps:
      - run: ...

Additional information

N/A

[TingluoHuang]

@tprk77
we are not supporting windows container for the following reasons:

• Extra windows version requirements, ex regular windows 10 desktop may not work with certain network/volume features
• We can't install docker-ce on GitHub windows hosted runner VM due to license issues.
• We have to install docker-ee which is usually 6-12 months behind docker-ce on feature and bug fixes.
• Container on Linux and Windows are not feature parity.
• Windows is just not good at supporting containers.

[tprk77]

That's too bad, but it seems there is good justification for not supporting Windows container.

However, I don't see why this isn't mentioned in the documentation of jobs.<job_id>.container. It would be really easy to include a line saying that it only works on Linux runners, and would prevent people form wasting their time trying to use it like I did.

Should I open another ticket for the documentation?

[jelmansouri-legion]

Is Microsoft, improving/planning on maintaining container support or is the plan to deprecate it at some point? If the latter I understand it's not worth the time of devs and GitHub. If not, maybe even with some restrictions, it might be worth allowing some workflow to used them, as long as the non supported cases are documented.
Since the documentation wasn't explicit about the ability to use the container operations on windows, I gave it a try. It yielded the same reported error above. As a workaround, I ended up doing this:

      - name: Build
        run: >-
          docker run
          --name cargo_test
          --rm
          --workdir ${{ matrix.workdir }}
          -v ${{ github.workspace }}:${{ matrix.workdir }}
          ${{ matrix.container }}
          cargo test --no-run

[Kleptine]

Is this ever going to be on the roadmap? At the moment this bans a fairly large number of actions from ever working on Mac or Windows, which splits the ecosystem pretty dramatically for anyone trying to build cross platform software.

I understand the above licensing issues, but as Docker becomes more stable on Windows, the issues with using docker-ee seem like they would diminish. Presumably we'll get to a point where docker-ee being 6 months behind on bug fixes isn't an issue?

[neersighted]

Hi, I'm an engineer who works on the product formerly known as Docker EE (and now known as Mirantis Container Runtime). We work in the upstream Moby project on a daily basis to ensure our product is as close to upstream Moby as possible, and count several maintainers among our team.

I'd love to understand why GitHub needs MCR (Docker EE) over a from-source build of Moby. I'd also love to determine if we can do something as Mirantis to help GitHub support this for all open-source projects. If you're from GitHub, please reach out -- I'd be very happy to discuss upstream Moby and its development process/licensing, MCR's lifecycle (we usually deliver patches in a matter of weeks, but historically version numbers have not been aligned, and this may be the source of confusion), and any other questions/concerns you may have.

[thecloudtaylor]

@tprk77 we are not supporting windows container for the following reasons:

• Extra windows version requirements, ex regular windows 10 desktop may not work with certain network/volume features
• We can't install docker-ce on GitHub windows hosted runner VM due to license issues.
• We have to install docker-ee which is usually 6-12 months behind docker-ce on feature and bug fixes.
• Container on Linux and Windows are not feature parity.
• Windows is just not good at supporting containers.

@TingluoHuang - I am the group product manager for Windows containers. I disagree with a set of these assertions and very much disagree with the over decision as clearly from this discussion and many others we have had there is customer need for this support.

To the points:
#1 (Win 10 etc...) - Firstly, I'm not sure why this is even relevant to the discussion. While of course developers leverage Windows client while building applications the build pipeline and production usage of them is on Windows Server.

#2 (Docker CE) - You can use Moby (to @neersighted's point).

#3 (MCR delays) - I would be very interested to understand what features fixes, specific to Windows containers, you where delayed on? The Mirantis team has typically been very active at incorporating blocking issues into EE builds.

#4 (feature parity) - The first priority/goal of Windows containers is enabling customers a part forward for there Windows Server applications. There are definitely features on our roadmap that will enhance that further but we believe and have many customers in production that have been very successful moving apps forward. There are a whole host of Linux features/functionality that just simply don't make since in a Windows world. Just as there are Windows features that don't make since in a linux world.

#5 (windows is not good at hosting containers) - I'm just going to leave this at argumentative and unproductive.

[knocte]

we are not supporting windows container for the following reasons:

Why was this closed as completed (instead of not planned) then?

[grochoge]

@TingluoHuang Half of your reasons aren't even true anymore since the Github Windows runners have the latest version of Docker installed on them.