pwsh shell command with dot sourcing fails, error status not returned with -File

[briantist]

I am trying to create a custom shell command in WSL that runs pwsh.

The regular github pwsh shell command is defined on all platforms as follows: pwsh -command ". '{0}'"
(see https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)

Unfortunately if I try to use that, I get a strange error:

ResourceUnavailable: Program '21a79fd1-1eb1-45b9-8d98-86a321c674a1' failed to run: An error occurred trying to start process '/mnt/d/a/_temp/21a79fd1-1eb1-45b9-8d98-86a321c674a1' with working directory '/mnt/d/a/repo/repo/powershell'. Exec format errorAt line:1 char:1
+ . '/mnt/d/a/_temp/21a79fd1-1eb1-45b9-8d98-86a321c674a1'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
Error: Process completed with exit code 1.

The steps leading up to this look like this:

      - uses: Vampire/setup-wsl@v2.0.1
        with:
          distribution: Debian
          additional-packages: |
            gss-ntlmssp
            cifs-utils
            wget
            ca-certificates

      - name: Install PowerShell
        shell: wsl-bash {0}
        run: |
          wget https://github.com/PowerShell/PowerShell/releases/download/v7.3.3/powershell_7.3.3-1.deb_amd64.deb
          sudo dpkg -i powershell_7.3.3-1.deb_amd64.deb || sudo apt-get install -f

      - name: Update shell
        uses: Vampire/setup-wsl@v2.0.1
        with:
          wsl-shell-command: pwsh -NoProfile -NonInteractive -NoLogo -ExecutionPolicy Bypass -Command ". '{0}'"

      - name: Install Pester
        shell: wsl-pwsh {0}
        run: Install-Module Pester -Force

---

My current workaround is to change the wsl-shell-command to this:

wsl-shell-command: pwsh -NoProfile -NonInteractive -NoLogo -ExecutionPolicy Bypass -File '{0}'

This works fine to execute the file, but it has a major drawback: if the script being runs ends in an error, it does not fail the step in the workflow. This is I think a well-known pain point when running PowerShell scripts, which I believe the dot sourcing method that GitHub uses for its native pwsh/powershell steps gets around nicely.

Only thing is that I can't figure out how to make that form work with this, and the error message is quite confusing. I've tried changing around the quotes (like -command '. "{0}"') but it's the same error. It kind of seems like any attempt at all to use double quotes results in the error but I may be mistaken.

I'd really appreciate any insight you have on either being able to use the dot source form, or getting a failed step to actually fail.

[Vampire]

I don't think this has anything to do with the quotes or my action.
The quotes should work just fine.

To verify that, I used upterm to connect via SSH to the running WSL in the GitHub action.
There I did echo 'Install-Module Pester -Force' >/mnt/d/a/_temp/5d790ec0-d85c-4a27-818a-bec86ccd3414.
Then pwsh.
And there . /mnt/d/a/_temp/5d790ec0-d85c-4a27-818a-bec86ccd3414.

This gives the same error.

Here your steps modified so that you could try yourself:

      - uses: Vampire/setup-wsl@v2.0.1
        with:
            distribution: Debian
            additional-packages: |
                gss-ntlmssp
                cifs-utils
                wget
                ca-certificates
                openssh-client
                tmux

      - name: Install PowerShell
        shell: wsl-bash {0}
        run: |
            set -x
            wget https://github.com/PowerShell/PowerShell/releases/download/v7.3.3/powershell_7.3.3-1.deb_amd64.deb
            sudo dpkg -i powershell_7.3.3-1.deb_amd64.deb || sudo apt-get install -f
            wget -O - https://github.com/owenthereal/upterm/releases/download/v0.7.6/upterm_linux_amd64.tar.gz | tar zxvf - -C /tmp upterm && sudo install /tmp/upterm /usr/local/bin/
            if ! [ -e ~/.ssh/id_rsa ]; then ssh-keygen -q -t rsa -N "" -f ~/.ssh/id_rsa; ssh-keygen -q -t ed25519 -N "" -f ~/.ssh/id_ed25519; fi
            echo -e "Host *\nStrictHostKeyChecking no\nCheckHostIP no\nTCPKeepAlive yes\nServerAliveInterval 30\nServerAliveCountMax 180\nVerifyHostKeyDNS yes\nUpdateHostKeys yes\n" >>~/.ssh/config
            cat ~/.ssh/config
            ssh -i ~/.ssh/id_ed25519 uptermd.upterm.dev || true
            cat ~/.ssh/known_hosts
            cat <(cat ~/.ssh/known_hosts | awk '{ print "@cert-authority * " $2 " " $3 }') >> ~/.ssh/known_hosts || true
            cat ~/.ssh/known_hosts
            tmux new -d -s upterm-wrapper -x 132 -y 43 "upterm host --server 'ssh://uptermd.upterm.dev:22' --force-command 'tmux attach -t upterm' -- tmux new -s upterm -x 132 -y 43"
            sleep 2
            tmux send-keys -t upterm-wrapper q C-m
            tmux set -t upterm-wrapper window-size largest; tmux set -t upterm window-size largest
            sleep 1
            upterm session current --admin-socket ~/.upterm/*.sock
            sleep 9999999999

Then watch the action execution and you see the connection details.

[briantist]

Thank you very much @Vampire ! You are correct and this indeed has nothing to do with the action, nor the quotes, but you've helped push me in the right direction anyway.

The issue is partially within PowerShell, in that it won't dot source a script without the .ps1 extension. Based on the error, I also assume there's a shebang that could be added that might make it work without an extension, but I wasn't able to get that to work locally on my system (which may have been a local configuration issue).

In addition to the dot source syntax that GitHub uses in their own pwsh shell implementation, they also automatically add the .ps1 extension to those scripts so that then you refer to {0} that path has the extension already.

I was able to get dot sourcing working with this rather awkward shell command:

pwsh -NoProfile -NonInteractive -NoLogo -ExecutionPolicy Bypass -Command "Rename-Item '{0}' '{0}.ps1' ; . '{0}.ps1'"

However, this doesn't solve the exit code issue anyway, which I think is a different powershell issue (and I'm not sure how/why it works at all in GitHub's "native" powershell implementations). I really XY-problem'd myself here.

---

So I've now got this workaround:

          wsl-shell-command: >
            pwsh -NoProfile -NonInteractive -NoLogo -ExecutionPolicy Bypass -Command "
            \$ps1 = '{0}.ps1' ;
            Move-Item -LiteralPath '{0}' -Destination \$ps1 -Force ;
            Add-Content -LiteralPath \$ps1 -Value ';exit (-not \$?)' -Force -ErrorAction Stop ;
            . \$ps1
            "

It's kind of messy, but it seems to work!

One thing that could help make this cleaner is if we had an option in this action to add any arbitrary extension to the script file being executed. That would avoid the move at least.

I would also have preferred to do some of these steps in the wrapper script (batch file), and tried to do it with content preceding pwsh -NoProfile... but of course that didn't work because the command goes right after a wsl call. For this use case, if I could modify the file beforehand in the batch, I would have no need to rename it because I can go back to using the -File parameter.

Maybe we could have an option for some pre-command lines that end up in the wrapper script right before the call? So like:

      - name: Update shell
        uses: Vampire/setup-wsl@v2.0.1
        with:
          wsl-shell-wrapper-preamble: |
            echo ";exit (-not $?)" >>'{0}'
          wsl-shell-command: pwsh -NoProfile -NonInteractive -NoLogo -ExecutionPolicy Bypass -File '{0}'

---

Another possibility is to add first(ish)-class support for by automatically defining wsl-pwsh (user still has to ensure it's installed in the distribution), using some of the above methods, to make using pwsh from WSL easier. That would still allow for overriding it by redefining.

I don't know how useful any of the above changes would be more widely; if you'd consider implementing them or accepting a PR for them, let me know!

[Vampire]

However, this doesn't solve the exit code issue anyway, which I think is a different powershell issue (and I'm not sure how/why it works at all in GitHub's "native" powershell implementations). I really XY-problem'd myself here.

Not sure what you mean by "exit code issue", as you didn't mention exit codes before, but I guess what you mean is, that it does not fail on error.
That seems to be by design with PowerShell scripts if you don't call exit: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_scripts?view=powershell-7.3#returning-an-exit-value

One thing that could help make this cleaner is if we had an option in this action to add any arbitrary extension to the script file being executed. That would avoid the move at least.

Well, the move would be necessary either way, just done by the action.
It is GitHub Actions that writes this file.
I think GitHub Actions would be the right project to request such a feature from, to be able to specify an extension for the script file generated for run steps.
I don't think that this action is the proper place to add such a feature.

Maybe we could have an option for some pre-command lines that end up in the wrapper script right before the call? So like:

I'm not sure how much I like that idea either.
Especially as for example {0} is not what is actually used in the script.
And if you for example would need to still rename the file, you would need to set a variable, that is more an implementation detail,
so I would either make such internals "official API" regarding backwards compatibility or your workflow would be prone to fail with every patch release.

Another possibility is to add first(ish)-class support for by automatically defining wsl-pwsh (user still has to ensure it's installed in the distribution), using some of the above methods, to make using pwsh from WSL easier. That would still allow for overriding it by redefining.

I'm afraid also this is not really in the scope of the action imho. It defines one wrapper per invocation and by default one that is available almost anywhere and still has a check that it really is available.
If I would add a dedicated pwsh wrapper too that is always generated, it is a bit against the current principle of the action and also make things awkward.
Mainly because Microsoft loves destroying things. For example the wsl.exe has many variations with quite different capabilities and not even a --version argument that can help in determine compatibilities.
Or wslconfig.exe suddenly started to output text in a different encoding without further notice.
I'm currently invoking --help on such tools and decode the output bytes in two encodings, then check the content to determine which tool supports which options and what I have to call.
I don't really want to add support for a generic pwsh wrapper that then has to be compatible with all possible pwsh versions you might happen to have installed within the WSL distribution.
That is imho a task for your workflow that creates a wrapper that is compatible with your exact situation.

How about something like this which might maybe be a bit cleaner than the excessive wsl-shell-command:

- name: Prepare pwsh-wrapper
  shell: wsl-bash {0}
  run: |
      cat <<'EOS' >/usr/local/bin/my-pwsh
      set -euo pipefail
      echo ';exit (-not $?)' >>$1
      mv $1{,.ps1}
      pwsh -NoProfile -NonInteractive -NoLogo -ExecutionPolicy Bypass -Command ". '$1.ps1'"
      EOS
      chmod +x /usr/local/bin/my-pwsh

- name: Update shell
  uses: Vampire/setup-wsl@v2.0.1
  with:
      wsl-shell-command: my-pwsh '{0}'

- name: Install Pester
  shell: wsl-my-pwsh {0}
  run: Install-Module Pesterzzz -Force

[briantist]

Ok, I understand the hesitation on those features, thanks for considering!

How about something like this which might maybe be a bit cleaner than the excessive wsl-shell-command

That looks nice, I may try that out.

Thanks very much for your time!