Unknown system error on macos-13 runner

[viirya]

Hi,

We have GitHub Actions CI pipelines on both macos-14 and macos-13 runners. But on macos-13 runner, we saw the following error:

Run codecov/codecov-action@v3
  with:
  env:
    RUST_VERSION: stable
    DYLD_LIBRARY_PATH: /usr/local/opt/openssl@3/lib:
    JAVA_HOME: /Users/runner/hostedtoolcache/Java_Zulu_jdk/17.0.12-7/x64
    JAVA_HOME_17_X64: /Users/runner/hostedtoolcache/Java_Zulu_jdk/17.0.12-7/x64
==> macos OS detected
https://uploader.codecov.io/latest/macos/codecov.SHA256SUM
==> SHASUM file signed by key id 806bb28aed779869
==> Uploader SHASUM verified (75086ee436f6f74c4e8f65448eaa399e38bc93bb27a53d057b24b275b9f78c89  codecov)
==> Running version latest
==> Running version v0.8.0
/Users/runner/work/_actions/codecov/codecov-action/v3/dist/codecov -n  -Q github-action-3.1.6
Error: spawn Unknown system error -86
    at ChildProcess.spawn (node:internal/child_process:421:11)
    at Object.spawn (node:child_process:761:9)
    at ToolRunner.<anonymous> (/Users/runner/work/_actions/codecov/codecov-action/v3/webpack:/codecov-action/node_modules/@actions/exec/lib/toolrunner.js:413:1)

It looks like the architecture doesn't match. According to the docs, codecov-action supports macos, I'm wondering if it supports both 13 and 14 runners?

[zhongjiajie]

same here in apache/dolphinscheduler-sdk-python#150

[corhere]

• The root cause is macOS binary is not x86_64 but arm64 uploader#1687

(System error -86 is -EBADARCH -- Bad CPU type in executable.)

It can be worked around by configuring the action to use v0.7.3 of the uploader, which was built for Intel macs.

with:
  version: v0.7.3

[thomasrockhu-codecov]

@viirya @zhongjiajie @corhere I realize it's been quite a long time on this issue. Are you experiencing this problem on v5?

[viirya]

We use tokenless uploading so currently we use v3. Does v5 support tokenless uploading?

[thomasrockhu-codecov]

@viirya, tokens are always required for private repos

1. Without forks, tokenless is only supported as an org-level setting for public repositories
2. With forks, tokenless should be supported fully
3. If (1) is not an option, I recommend using OIDC instead of a token, super easy to set up

[thomasrockhu-codecov]

@viirya just wanted to message back and see if I can help here

[thomasrockhu-codecov]

@viirya closing this out, if this is still a problem, please let me know

[viirya]

@viirya, tokens are always required for private repos

1. Without forks, tokenless is only supported as an org-level setting for public repositories
2. With forks, tokenless should be supported fully

Do you mean that if our repo allows contributors to fork and make PRs, it must have tokenless support (we currently use it)?

Our repo (https://github.com/apache/datafusion-comet) is an open source Apache project, so it is definitely not a private repo.

3. If (1) is not an option, I recommend using OIDC instead of a token, super easy to set up

So you mean to upgrade to v5 (no tokenless support), we must use OIDC?

[thomasrockhu-codecov]

Do you mean that if our repo allows contributors to fork and make PRs, it must have tokenless support (we currently use it)?

This should work as expected

Our repo (https://github.com/apache/datafusion-comet) is an open source Apache project, so it is definitely not a private repo.

Then no worries on that!

So you mean to upgrade to v5 (no tokenless support), we must use OIDC?

To be clear, v5 has tokenless support for forks. I mention OIDC because it seems that our users come across less issues and it's fairly easy to set up (adding permissions in the GitHub workflow and adding use_oidc: true as a Codecov argument)

[viirya]

Let me try to upgrade to v5 and see if tokenless is back on macos-13 runner. We can look at OIDC later.

[viirya]

v5 works with macos-13 runner without this issue.

[viirya]

Thank you @thomasrockhu-codecov