Support Windows Containers

[sirredbeard]

Describe the enhancement

Support for Windows Containers in the GitHub Actions runner, even if only available on self-hosted runners, as in:

jobs:
  build:
    runs-on: windows-2022
    container:
      image: docker.pkg.github.com/sirredbeard/nim-windows-container/nimstable-ltsc2022:latest
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}

Currently GitHub Actions can be used to build and push Windows Containers to the GitHub Container Registry however GitHub Actions cannot pull Windows Containers to use for building or testing.

This is unfortunate and limits the adoption of Windows Containers for use on GitHub.

[ChristopherHX]

You can try my fork of the runner /~https://github.com/ChristopherHX/runner.server/releases/latest

I reenabled disabled windows container support of this azure pipelines agent fork ( which has this feature ). At least it worked with docker desktop on windows.

Auto updates are disabled. ( version 3.3.2 >= actions/runner 2.xxx.x )

[ethomson]

At this time, the inconsistencies in container support across different versions of Windows make this undertaking very difficult. At this time, we don't have any plans to enable Windows containers. I'll put this on the backlog for the future.

[SS1823]

Hi, I've posted a small patch in PR #1801
I've tested it successfully, as in it compiles code using steps inside dockerized windows server 2019 with msvc 2017, cmake and conan installed.
It'd be nice if someone from GH chimed in on the patch, to get it up to GH standards, and upstream it.
I'm willing to put some work in as it'll save time compared to using workarounds

[Danielku15]

@ethomson A lot of time passed since your post and times changed quite a bit since then. What would be the latest reasons to not support windows containers? And if there are concerns not to provide it (yet?) on GitHub.com, would there speak anything against an experimental opt-in for self-hosted runners?

While I understand that there might be various implications on Windows containerization and nested virtualization with different hypervisors. Having an opt-in for testing and evaluation would be already a huge benefit for those who are able to provide an environment where windows containers are supported.

The biggest risk I see is that people would start reporting bugs if things are not working and it might be time consuming to troubleshoot and assist those customers.

We are using /~https://github.com/actions/actions-runner-controller in our GHES environment and certainly would like to use containerized workflows and steps.

[chadmyers]

Is this issue a dupe of #904?

[sirredbeard]

Closing in favor of #904