@emoon,

Running this locally works just fine.

Please try to install a self-hosted runner on the local machine, then use this self-hosted runner to run the “build_windows” job to see if the problem still exists.
In this way, you do not need the “Install Qt” step in the workflow if you have installed Qt on the local machine.

Not sure if the “jurplel/install-qt-action@v2” action has setup the completed required Qt environments on the runner.

Thanks for the reply.

I can test a local runner. Right now I simply tried to remove the Qt install now and I get the same issue with the remote (default) runner. The script looks like this now

  build_windows:
    runs-on: windows-latest
    steps:
    - uses: actions/checkout@v2
#    - name: Install Qt
#      uses: jurplel/install-qt-action@v2
#    - name: Env test
#      run: |
#        echo "Testing"
#        echo %Qt5_DIR%
#        echo "Testing 2"
#        set QT5_BIN=%Qt5_DIR%/bin
#        echo %QT5_BIN%
    - name: Build Release
      shell: cmd
      run: bin\windows\tundra2.exe win64-msvc-debug

So all it’s doing is to checkout the repo and try to run the executable and with the same result. I will likely try to just build the executable used from source instead and see if it works then.

@emoon,

It’s strange that the command “bin\windows\tundra2.exe win64-msvc-debug” can work fine if you directly run it on your local machine that has Qt installed, but does not work when running on the self-hosted runner installed on this machine.

There may be some issues occur when run this command via the runner application.
I have create an internal issue ticket to report this problem to the appropriate engineering team for further investigation and evaluation. If they have any progress, I will notify you in time, and sometimes the appropriate engineers may directly reply you here.

Thanks!

Also notice that this application doesn’t require Qt to be installed. It do rely on scripts and files that are included in the repository but if something of those should be missing the program should report it. Right now it seems like Windows can’t run the executable at all for some reason.

Hey, some more updates here: It actually turns out that the tundra2.exe executable gets started and the CreateProcess failed() gets reported by the program itself.

I tracked it down to this code

    if (!CreateProcessA(NULL, GetCommandLineA(), NULL, NULL, TRUE, CREATE_BREAKAWAY_FROM_JOB|CREATE_NEW_PROCESS_GROUP|CREATE_SUSPENDED, NULL, NULL, &startup_info, &proc_info))
      CroakErrno("CreateProcess() failed for %s error %d", GetCommandLineA(), GetLastError());

And I added some more info now and the output is

CreateProcess() failed for "D:\a\HippoPlayer\HippoPlayer\src\external\tundra\vs2017\x64\Release\tundra2.exe" error 5

(I have added the source code to the repo so I can do changes to it) the 5 is the error code from GetLastError() which is

ERROR_ACCESS_DENIED
5 (0x5)

Access is denied.

So for some reason the code above isn’t allowed create a new process. I will speak with the author of this code, but I still find it strange it doesn’t run correct on the builder instance.

Hello, @emoon
I have created a bug - actions/runner#595

Thanks! Great bug report :slight_smile: