Using WSL1 github workflows

[Sorin Sbarnea]

• All default GHA runners can only use WSL1, so we cannot make use of docker or podman on them.
• We might be able to spawn our own runners that would be able to make use of WSL2

Tricks about easily integrating WSL1 actions

Here is a model that should allow us to use WSL, as it includes few tricks we need to consider.

Do not try to use expressions inside shell: for specific steps as that is not allowed. Still the trick with defaults works fine.

One important observation is that env: does not reach WSL job by default, so we need to pass environment variables manually. Read Vampire/setup-wsl#9

jobs:
    runs-on: ${{ matrix.os }}
    env:
      FORCE_COLOR: 1
      # colon separated list of env vars to be passed to wsl-bash:
      WSLENV: FORCE_COLOR:TOX_ENV
    defaults:
      run:
        shell: ${{ matrix.shell || 'bash'}}
    matrix:
      ...
      include:
        - os: windows-latest
          shell: "wsl-bash {0}"

    steps:
      - name: Activate WSL1
        if: "contains(matrix.shell, 'wsl')"
        uses: Vampire/setup-wsl@v1

      - run: echo 123
        env:
          TOX_ENV: foo  # do not forget to include it in WSLENV

      - # run a command directly under Windows (not wsl)
        run: dir
        if: "runner.os == 'Windows'"
        shell: bash  # or other but cannot omit it, else will be under wsl

[Brian Scholer]

It's good to see this, I've been experimenting with WSL in GHA myself, as a way of being able to test ansible Windows stuff. I did get it working but there are quirks. I tested with Windows 2019 and Windows 2022, and with Ubuntu 20.04 and Debian on each.

My biggest problem so far is that on Windows 2022 + Debian (only this combination), running any ansible command seems to completely lock up the runner. It will time out or if I cancel, it will ignore the request until the cancel times out and it gets killed.

I picked it back up today and started playing with it again, but now, weirdly, Ubuntu-20.04 as stopped installing via the Vampire action (missing from hostedtoolscache it seems), so I don't know what's going on there either.

[Sorin Sbarnea]

TBH, I do not expect to see Ansible really fully working on WSL1 because machine does not have a full linux Kernel. I guess that is the reason why is written everywhere that only WSL2 should be used.

Still, for linting purposes we don't effectively connect to any remote hosts, so we might get lucky. Since yesterday we have wsl1 pipeline on linter and now I am working to add it to the language server. Take a look at these, i hope it will help you, also feel free to ping me on matrix, maybe we can have more progress.

[Brian Scholer]

TBH, I do not expect to see Ansible really fully working on WSL1 because machine does not have a full linux Kernel. I guess that is the reason why is written everywhere that only WSL2 should be used.

I can definitely offer insight here! Where I work, WSL has been what we use for running Ansible (controller) on Windows since before WSL2 existed. There are no issues with Ansible specifically in WSL1.

WSL2 is recommended more generally because the full kernel means it can support more things natively (for example Docker Desktop on Windows has an integrated WSL2 mode so that containers can share the kernel and run in the same process that hosts WSL), and especially because filesystem performance is much, much higher.

Most engineers at the company use a mac though, and the subset of engineers who have a mac workstation, but also need to use Ansible to connect to Windows, tend to run it in WSL1 in Windows in Parallels (can't support WSL2 in that configuration), because of the various issues running Ansible natively in MacOS, especially when using Kerberos.

We have a containerized Ansible that mac users usually use but doesn't work for them when connecting to Windows (this is because of reasons specific to our Windows/Ansible workflow at present, it's not a technical reason).

So even though most of our Windows workstation users have switched to WSL2, we still have WSL1 in use as well.

Still, for linting purposes we don't effectively connect to any remote hosts, so we might get lucky. Since yesterday we have wsl1 pipeline on linter and now I am working to add it to the language server.

I'll add that in both cases (WSL1 & WSL2), vscode with remote-wsl is used by us extensively.

The only issues I've ever seen relates to vscode + WSL1, and it has to do with the filewatcher; the settings have to be tweaked to not cause permissions issues or performance issues on WSL1. None of that should end up being a concern for the language server or Ansible purposes specifically though. The issues I described above and the settings to deal with them are well-documented though.

Take a look at these, i hope it will help you, also feel free to ping me on matrix, maybe we can have more progress.

Sure, and I'm happy to help as well where I can, WSL + vscode is where I have spent the majority of my workday for over 4 years now. I'm around in the Ansible channels (I still connect via IRC) as briantist.

[Sorin Sbarnea]

@briantist Any idea on how to sort the problem I found: I need to add ~/.local/bin to WSL path but adding it .bashrc does not work as apparently when you run WSL that file is not loaded.

That is important because I have multiple run: GHA steps and I need them to be able to have this in their PATH, as that is where I add some required testing dependencies.

[Brian Scholer]

I saw the discussion you opened in the action's repo and posted an answer there: Vampire/setup-wsl#22 (comment)

FWIW, .bashrc does get loaded normally when I use WSL locally, that's how I've been setting environment variables and such since I first started using WSL. .bash_profile also gets loaded. I think in the action it's a matter of the invocation that changes that.

And although it's a little old, this issue seems to go over the finer points of which file is loaded and when:
microsoft/WSL#2816