Setting output path fails(?) using PowerShell running on windows-latest via mcr.microsoft.com/windows/servercore:ltsc2022

[kohanyirobert]

Hey! I found your project after realizing act can't run workflows via Docker when working with Windows-based GitHub Actions workflows.

I managed to run your tool, but my workflow fails locally with this:

[Build / build] Running: Find .trx
| ##[group]Run $path = (ls -Recurse -Filter *.trx | select -First 1).FullName
| $path = (ls -Recurse -Filter *.trx | select -First 1).FullName
| "path=$path" >> $env:GITHUB_OUTPUT
| shell: pwsh -command ". '{0}'"
| env:
|   HUSKY: 0
|   NUGET_PACKAGES: C:\Users\rkohanyi\AppData\Local\runner.server\a\rn3igp3j.scv\w\DisplayDetective\DisplayDetective/.nuget/packages
|   DOTNET_ROOT: C:\Program Files\dotnet
| ##[endgroup]
| '$path' is not recognized as an internal or external command,
| operable program or batch file.
| ##[error]Process completed with exit code 255.

Here's my workflow file., this is the interesting part:

      - name: Find .trx
        id: trx
        run: |
          $path = (ls -Recurse -Filter *.trx | select -First 1).FullName
          "path=$path" >> $env:GITHUB_OUTPUT

Basically I try to dynamically find a file and set an output (as described in the official docs).

On GitHub Actions this works, here's one of my runs (the run fails eventually, but this steps works).

Any idea? I'm unsure I'm doing something wrong or is this a bug.

This is how I run the runner: dotnet runner.client pull_request -W .\.github\workflows\build.yml -P windows-latest=mcr.microsoft.com/windows/servercore:ltsc2022 --ref 'feat/ci-test-reporter'

[ChristopherHX]

I guess the problem here is you pwsh script is run using cmd (for the same reason sh is used for linux job containers). (that the log shows pwsh instead of cmd is a bug inherited by the actions/runner, where it only applies to linux)...

My app basically rewrites your workflow a bit to have the container field set, but you are right making powershell default makes sense if you use the -P windows-latest=image syntax.

Please try the following

      - name: Find .trx
        id: trx
        run: |
          $path = (ls -Recurse -Filter *.trx | select -First 1).FullName
          "path=$path" >> $env:GITHUB_OUTPUT
        shell: powershell # or pwsh

or put above your job, this makes your shell decision permanent without using defaults

defaults:
  run:
    shell: powershell

Does mcr.microsoft.com/windows/servercore:ltsc2022 contain powershell or pwsh? if not you need to change your image.

[kohanyirobert]

that the log shows pwsh instead of cmd is a bug inherited by the actions/runner, where it only applies to linux
Wow, did not expect that to happen.

Thanks this fixes the problem (although I have another one down the pipe - an action not being able to comment on a PR).

[ChristopherHX]

@kohanyirobert You use bibipkins/dotnet-test-reporter@v1.5.0 that depends on a pull_request event that is available in your repository.
Adding a condition to skip it for github.event_name != 'pull_request' makes totally sense to me

The easiest is to skip that action using if: (!vars.LOCAL) and append --var LOCAL=1 to cli.

But if you want to diagnose issues with usage of that action, then here some hints.

• github.token required by -s GITHUB_TOKEN=gh_pat456hxeFjbduUhd68 or if gh cli is logged in (automatically) gh auth login
• --eventpath pull_request_webhook.json see https://docs.github.com/en/webhooks/webhook-events-and-payloads#pull_request (registering an pull_request webhook of your repository can provide you the exact payload)

BTW this one is similar extra work as in act, not every action works with a sparse ${{ github.event }} object.
if you log - run: echo '${{ tojson(github.event) }}' in your pr, you can use that as well for a pull_request_webhook.json file without adding a webhook. (just revert this once you found the problem)

[kohanyirobert]

Adding a condition to skip it for github.event_name != 'pull_request' makes totally sense to me

Yeah, next time I need to debug something I'll do something like that, I'm good for now. But your tool is super handy, great work man ✋

registering an pull_request webhook of your repository can provide you the exact payload

Great idea.

not every action works with a sparse ${{ github.event }} object

Yeah, I have expected as much, not a big deal, but thanks for the tips. They might come in handy later on :)