search

actions / runner-images

GitHub Actions runner images
MIT License
9.9k stars 3.01k forks source link

"The specified executable is not a valid application for this OS platform" on windows-latest 2023.0417.1 #7467

Closed idg10 closed 1 year ago

idg10 commented 1 year ago

Description

We have a build process that involves running an executable fetched by npm, but which we launch directly. (We don't run it via npm.)

Our last successful build ran on:

Image: windows-2022
Version: 20230314.1

Running a build of the same commit now fails. The Azure DevOps source card reports that the sources are the same. As far as we can tell, the only difference is that the build agent has updated:

Image: windows-2022
Version: 20230417.1

The failure occurs when running a dotnet test step. The tests run, so the problem isn't with launching the test runner. The problem is that our tests attempt to run the Azure Functions host, which fails with this error:

  Error Message:
   System.ComponentModel.Win32Exception : An error occurred trying to start process 'C:\npm\prefix\node_modules\azure-functions-core-tools\bin\func' with working directory 'd:\a\1\s\solutions\Corvus.Testing.AzureFunctions.DemoFunction\bin\release\net6.0'. The specified executable is not a valid application for this OS platform.
  Stack Trace:
     at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
...

As you can see we're trying to run the func program that is included in the azure-functions-core-tools package downloaded from NPM. This has worked just fine for years, and continues to work when running locally. It's only on Azure build agents that we see this problem.

We don't believe that this Azure Functions tool has changed. The current version is 4.0.5095, which was also the current version when our last successful build ran. So the executable we're trying to launch certainly used not to cause this error.

So we're wondering if some new constraint has been created that limits launching of executables on build agents. When we run test code with dotnet test are we now not allowed to launch arbitrary executables as part of that?

Platforms affected

Runner images affected

Image version and build link

Image: windows-2022 Version: 20230417.1

https://dev.azure.com/endjin-labs/Corvus.Testing/_build/results?buildId=19060&view=results

Is it regression?

20230314.1

Expected behavior

We expect our test project to be be able to launch the func.exe downloaded as part of the Azure Functions Core Tools npm package.

Actual behavior

After having used this approach successfully for years, we are now seeing an error "The specified executable is not a valid application for this OS platform" when trying to launch the func.exe executable.

Repro steps

Install the Azure Functions Core tools, e.g.:

      - task: Npm@1
        displayName: 'Install Latest Azure Functions V4 Runtime'
        inputs:
          command: custom
          verbose: false
          customCommand: 'install -g azure-functions-core-tools@ --unsafe-perm true --verbose'

Run a step that executes a test that attempts to run an executable from the npm package just downloaded.

(Our repository is open source, so you can see it for yourself.)

milkyware commented 1 year ago

This seems to be similar to an issue I'm currently having. I'm also using the azure function core tools in a Ubuntu pipeline to spin up an OpenAPI function and then download the swagger definition to publish later on. When func start --port 5000 is used, I just get the error back of /usr/local/lib/node_modules/azure-functions-core-tools/bin/func: 2: Syntax error: Unterminated quoted string. This was working in Ubuntu 22.04 20230409.1 images, but no longer in Ubuntu 22.04 20230417.1 and Ubuntu 20.04 20230417.1.

I notice that the PowerShell version got bumped to 7.2.11, don't know if that's related at all

dec42nd commented 1 year ago

I'm also seeing issues on the ubuntu-latest image for 20230417.1. 20230409.1 works fine. Specifically, python fails to find a module to import while running tests, while it should be right there, just using the standard checkout flow. Would be great if there was a way to pin runner version, I'm convinced it's this new version that's causing issues.

Jabronironi commented 1 year ago

Having exact same error as @milkyware. Does anyone know if there is a way to pin the agent back to previous version while this gets resolved? My initial search said no. :( Side note: I am using bash with same issue, so I don't know if it is PS version related.

ggritco-dava commented 1 year ago

We also have an issue partially similar, on both GitHub Runners and on Azure DevOps Build Agents. The similar error output is thrown when using either func settings add or func start

Below is the info from our GitHub workflow run on func start

Current runner version: '2.303.0' Operating System Microsoft Windows Server 2022 10.0.20348 Datacenter Runner Image Image: windows-2022 Version: 20230417.1 Included Software: https://github.com/actions/runner-images/blob/win22/20230417.1/images/win/Windows2022-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/win22%2F20230417.1 Runner Image Provisioner 2.0.139.1

    - name: Install Azure Functions Core Tools
      run: npm i -g azure-functions-core-tools@4 --unsafe-perm true
...
    - name: Start Function App
      working-directory: ${{ github.workspace }}\BuildOutput
      shell: bash
      run: func start --no-build --csharp --useHttps --verbose --cert certificate.pfx --password ${{ *** }} &

Throws an error as:

...
node:internal/child_process:413
    throw errnoException(err, 'spawn');
    ^

Error: spawn UNKNOWN
    at ChildProcess.spawn (node:internal/child_process:413:11)
    at spawn (node:child_process:757:9)
    at main (C:\npm\prefix\node_modules\azure-functions-core-tools\lib\main.js:9:22)
    at Object.<anonymous> (C:\npm\prefix\node_modules\azure-functions-core-tools\lib\main.js:18:1)
    at Module._compile (node:internal/modules/cjs/loader:1254:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Module._load (node:internal/modules/cjs/loader:958:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:23:47 ***
  errno: -4094,
  code: 'UNKNOWN',
  syscall: 'spawn'
***

Node.js v18.16.0
Jabronironi commented 1 year ago

@ggritco-mrsk - same here. When I switched from ubuntu latest to windows latest - I get your error instead of the one @milkyware is getting.

Jabronironi commented 1 year ago

I noticed that most of the posted examples were using NPM to install azure function core tools. We were also using that approach. I switched to using APT to install the tools (for ubuntu image) and we were able to get past this issue. It specifically appears to be a combo of the new images (windows and ubuntu current versions) using the new image number 20230417.1 AND the npm install of the azure core functions.

alice-was-here commented 1 year ago

I'm also seeing issues on the ubuntu-latest image for 20230417.1. 20230409.1 works fine. Specifically, python fails to find a module to import while running tests, while it should be right there, just using the standard checkout flow. Would be great if there was a way to pin runner version, I'm convinced it's this new version that's causing issues.

Having the same issue with some python jobs... A specific install job ran fine 4 days ago, using the following image version: 

  Image: ubuntu-22.04
  Version: 20230409.1

Rerunning the exact same job picks up the new runner

  Image: ubuntu-22.04
  Version: 20230417.1

And then fails with 

  python3.8 -m pip install -t /home/runner/.cache/serverless-python-requirements/[...]_x86_64_slspyc -r /home/runner/.cache/serverless-python-requirements/[...]_x86_64_slspyc/requirements.txt --cache-dir /home/runner/.cache/serverless-python-requirements/downloadCacheslspyc
sergei-pyshnoi commented 1 year ago

Hello @idg10 . We will take a look.

ggritco-dava commented 1 year ago

I changed installation step from using NPM to use Chocolatey. Works for us.

    - name: Install Azure Functions Core Tools
      run: choco install azure-functions-core-tools
vpolikarpov-akvelon commented 1 year ago

Hi @idg10. Looks like there is a problem with the latest version of Node. https://github.com/Azure/azure-functions-core-tools/issues/3335

You may workaround it by downgrading Node to version 18.15:

    - task: NodeTool@0
      inputs:
        versionSpec: '18.15'
idg10 commented 1 year ago

Thanks @vpolikarpov-akvelon - that does seem to be the root cause of the problem I'm seeing, and your suggested workaround is working for me.

sergei-pyshnoi commented 1 year ago

@idg10 Look like problem is gone with image update, can you try your workflow without pinned node version 18.5?

idg10 commented 1 year ago

I've backed out our workaround (so we no longer pin to 18.5), and yes, that now seems to be working - thanks!