Add Windows Subsystem for Linux to Windows

[dcermak]

Tool information

• Tool name: Windows Subsystem for Linux
• Add or update? Add
• Desired version: latest
• Approximate size:
• If this is an add request:
  • Brief description of tool: Virtual Linux environment for Windows 10
  • URL for tool's homepage: https://docs.microsoft.com/en-us/windows/wsl/about

Virtual environments affected

• macOS 10.14
• Ubuntu 16.04 LTS
• Ubuntu 18.04 LTS
• Windows Server 2016 R2 (not sure if available here)
• Windows Server 2019

Can this tool be installed during the build?
No, it requires a reboot of the Windows machine.

Are you willing to submit a PR?
Willing yes, able: no (I have literally zero Windows experience). In theory you just have to run:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

as the administrator and reboot.

[TomasHubelbauer]

Are you willing to submit a PR?

Where exactly would one send a PR for this anyway, there's no agent provisioning code in this repo, no?
In any case, I'd like to vouch for this feature to be added!

[dcermak]

Are you willing to submit a PR?

Where exactly would one send a PR for this anyway, there's no agent provisioning code in this repo, no?

I don't think you can, at least I haven't found a way to do so.

[eine]

@dcermak, is there any specific advantage in installing WSL instead of using a proper MSYS2 installation (#30) and/or docker containers?

[TomasHubelbauer]

I feel like "proper" is a loaded word. In one way, WSL is a part of Windows and WSL2 is an actual Linux kernel, so one could argue that makes it more proper than MSYS2 which you need to install yourself and is a recompiled binary for Windows, not the actual Linux binary. I personally think WSL is more important to add, because you can (as I understand it) install MSYS2 yourself in the workflow run, not so much for WSL which needs to be enabled as a Windows component, which requires restart and at the current, the agents are not set up so that they could pick up a workflow run after their restart.

[dcermak]

eine <notifications@github.com> writes:

@dcermak, is there any specific advantage in installing WSL instead of using a proper MSYS2 installation (#30) and/or docker containers?

Yes, if you want to test a WSL image, you actually do need WSL ;-)

[eine]

Yes, if you want to test a WSL image, you actually do need WSL ;-)

@dcermak, so, you are implicitly asking for nested virtualization to be supported, isn't it? It seems that you don't want to just test WSL images as containers running on the existing Docker VM; instead you want to create your own VMs through WSL's cli.

---

@TomasHubelbauer, I feel that you might have misunderstood when I used proper. Currently, windows-latest includes chocolatey package mingw, which is a kind of outdated and limited distribution. AFAIK, that's the built-in bash shell. Instead, MSYS2 might be installed, which is what #30 is about. Therefore, with "a proper MSYS2 installation" I mean "MSYS instead of MINGW or Git for Windows". Moreover, as commented in actions/toolkit#165 (comment):

Should GitHub provide built-in msys2, mingw64, mingw32 and/or wsl shells (instead of just bash), many related issues would be fixed

I didn't mean to say that MSYS2 is better or worse than WSL(2). Those are completely different products, and target audiences are very different.

---

WSL is a part of Windows

@TomasHubelbauer, AFAIK, WSL(2) is not available in any version of Windows. You need HyperV support. Did it change?

WSL2 is an actual Linux kernel

AFAIK, WSL2 is based on HyperV VMs, which is where the actual kernel is located. Therefore, it is technically the same as Docker for Windows. Apart from that, WSL2 includes (borrows?) the compatibility layer that allows to use windows binaries from a shell with Linux syntax; which is what MINGW is about.

install MSYS2 yourself in the workflow run, not so much for WSL which needs to be enabled as a Windows component

I expect both MSYS2 and WSL to be enabled eventually. That's why this issue and #30 exist. Furthermore, GitHub was bought by Microsoft, so they might have interest on promoting their own tools.

Nevertheless, provided that Docker for Windows is already installed and available, I wonder what specific use case you have to depend on WSL. You should be able to run/use all the GNU/Linux binaries in containers. As for windows binaries, those work natively. The only feature I can think of is running windows binaries from a bash script. For that specific use, WSL2 seems overkill, and the already available bash (MINGW) should work.

Overall, I'm not trying to argue against adding this feature. I'm just trying to understand why would one need WSL, if Docker and MINGW are already available.

[TomasHubelbauer]

I did misunderstand, thanks for correcting me. You're right that you need HyperV, but I consider that to be a part of Windows like WSL, you don't need to install either, just enable (unless you're using the Home edition).

My use case is actually the same as Dan's (not exactly a WSL image, but something which revolves around WSL specifically), I have a project which as a part of it uses WSL and I want to test it end-to-end in the pipeline. I can't replicate the test in any other way, because it specifically deals with WSL. In my case that's WSL1, but I do hope GitHub enables WSL2 as well as soon as it hits general availability.

To provide a few more examples, I can imagine something like VS Code would benefit from this WSL support as well, as they have an extension which enables using the WSL file system as a remote file system, so that's something they could test. My project is similar in this way.

[eine]

Thanks for clarifying. I'm sorry that you both seem to be hitting one of the few cases (testing support for a default WSL installation) where there is no other workaround than actually using WSL(2). I hope that you get attention from GitHub/Microsoft employees, since this sounds like a relevant feature.

[TomasHubelbauer]

I did also ask if WSL could be enable-able without a restart at microsoft/WSL#4743, but alas it looks like something which is not technically feasible, so indeed looks like this support landing will be the only way.

[dcermak]

eine <notifications@github.com> writes:

> Yes, if you want to test a WSL image, you actually do need WSL ;-) @dcermak, so, you are implicitly asking for nested virtualization to be supported, isn't it? It seems that you don't want to just test WSL images as containers running on the existing Docker VM; instead you want to create your own VMs through WSL's cli.

I want to load a custom built WSL image inside a github action and run some simple tests for it. I assumed that this requires WSL to be installed.

[dakale]

Just for extra information, we found that (older, but not sure how old) installations of WSL add a bash executable to C:\WINDOWS\system32\bash.EXE which interferes with using run.shell: bash due to path ordering, and wsl bash not handling absolute paths on the windows host

My understanding is that bash.EXE is being deprecated, but Im not sure if that means in WSL2 or what

In short, just be aware that blindly installing this may interfere with how we currently run bash scripts on Windows