Windows-hosted act_runner seems a bit rough around the edges


I’m having two questions, I have a bit of trouble when setting up a self-hosted runner.

  1. Is it possible that act_runner on windows does not support composite actions yet? My YAML looks like this:

My current yaml file looks a bit like

name: Build, test and deploy
on: [push]

  "Build, test and deploy":
      fail-fast: false
    runs-on: windows-2022
        shell: powershell
      - name: Identify trigger
        run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event."
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
          python-version: "3.11"
      - name: Run image
        uses: abatilo/actions-poetry@v2
          poetry-version: "1.5.1"

and this is hosted on a Windows 10 machine. I’m not really getting the poetry action to run properly though - looking into the actions’ repo, I’m seeing that this part is used as a “composite action”:

I see in the debug logs:

[Build, test and deploy/Build, test and deploy] [DEBUG] expression 'format('pip install poetry=={0}
', inputs.poetry-version)' evaluated to '%!t(string=pip install poetry==1.5.1
[Build, test and deploy/Build, test and deploy] [DEBUG] Wrote command

pip install poetry==1.5.1

 to 'workflow/'
[Build, test and deploy/Build, test and deploy] [DEBUG] Failed to setup Pty Unsupported
| /bin/bash: C:/Users/xxx/.cache/act/7e9028cfc1cb68ec/act/workflow/ No such file or directory
[Build, test and deploy/Build, test and deploy]   ❌  Failure - Main pip install poetry==1.5.1

So it looks like the action tries to run bash which is not installed on Windows. The action however claims to be compatible with it - my guess is that I don’t really understand composite actions or that there is something going on with act_runner trying to run on WSL which I am not realizing.
Can someone enlighten me a bit on this?

  1. I kinda circumvented that for now by just removing these steps and just manually installing the things that I need.

What I find more annoying though is that I don’t see the response in the fields on my Gitea webpage. I had configured the ‘standard labels’ (Ubuntu) yesterday and there I got some response back. Interestingly, the ‘Set up job’ point has some content. Anyone an idea what the reason could be?

Interestingly, if I remove

        shell: powershell

from my config, I get my output back on the webpage, however then already the first real action is failing.

[Build, test and deploy/Build, test and deploy] [DEBUG] Wrote command

echo "🎉 The job was automatically triggered by a push event."

 to 'workflow/0'
[Build, test and deploy/Build, test and deploy] [DEBUG] Failed to setup Pty Unsupported
| /bin/bash: C:/Users/xxx/.cache/act/df2ba9axxxf/act/workflow/0: No such file or directory

First of all, it seems like /bin/bash is called again, which makes not much sense for Windows. I had expected that act_runner would by default fall back to pwsh but that’s not the case. The Failed to setup comment is a bit puzzling - but setting up powershell as the shell to use is apparently also not the answer, or it is and Gitea does not handle this cleanly. So any heads-up here would be appreciated.

And yes, Windows is an 80%-hard requirement for this task for now. :slight_smile:

Answering part of this for myself for other readers:

So why exactly powershell is not forwarded back to Gitea is something I haven’t figured out so far but I got my output back by using Git bash instead. In that way I can still run my windows programs (unlike using WSL, where I wouldn’t be so sure or would need to be very specific all the time). For this I needed to make sure that the git-bash-path entry has higher priority than System32, which I did and now I have that output back.

After literal days of trying out what it could be I figured another big chunk out and that could be interesting for others to a point where my pain points are resolved sufficiently well and/or I have understood what can be done.

’act_runner’ seems to have a problem with unknown UTF8-characters which for some reason lead to a bug (IMO, I have not verified this, just from trying out a lot of things) in which the stream that forwards what happens on the worker side back to Gitea either gets destroyed or just stays not reactive anymore.

This lead in my case often to the post-task hanging indefinitely and no output being shown, which was caused by the bullet points from poetry (the Windows executable) being unrecognisable characters. Once I truncated the output before the bullet points would need to be printed, everything worked.

Now I haven’t fully worked out why the containers don’t work but from having long discussions on Discourse it looks like it’s a combination of this and Windows-containers not being supported (yet?).

I had the exact same issue on poetry with Gitea actions. My job was dying but then the Job Completed step hung indefinitely. Do you know if there is an issue on the gitea repository to address this?