[BUG] codecov-action@v5 uploader won't run on older OSes

[ktbarrett]

Describe the bug
Running codecov/codecov-action@v5 uploader on RHEL8 fails with

Failed to load Python shared library '/tmp/_MEIu0fyjN/libpython3.9.so.1.0': dlopen: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/_MEIu0fyjN/libpython3.9.so.1.0)

Expected behavior
I'm not sure who is providing your libpython builds or if you are doing it yourself, but consider using a libpython.so built with an older toolchain to support older OSes.

Also I expect this to be a failure, but the step "succeeds". But perhaps that's a change in v5 I haven't looked into yet.

Product Area
CI coverage upload.

Versions

• OS: RHEL8
• Git Host: Github
• CI/CD: GitHub Actions
• Uploader: codecov-action@v5

Commit and CI link
https://github.com/ktbarrett/find_libpython/actions/runs/15396229320/job/43317593248#step:7:224

[spalmurray]

Hey @ktbarrett - it seems like you just upgraded. Can you give me an example run of v4 working? I'm pretty sure v4 shouldn't work on this platform either unless certain things are true, so want to confirm.

[spalmurray]

and the success even though fail thing can be addressed by the action option:

uses: codecov/codecov-action@v5
  with:
    fail_ci_if_error: true

[ktbarrett]

Yeah looks like v4 also had this issue. Perhaps it was v3 since it last worked. Maybe this is less of a regression and more of a request then. RHEL8 is still in extended support and uses glibc 2.28.

[spalmurray]

@ktbarrett can you try

uses: codecov/codecov-action@v5
  with:
    use_pypi: true

This should use our pypi package instead of a pre-built binary and should be more widely compatible. I think it will require python >= 3.9 though, which may also be an issue for you.

[ktbarrett]

That will work if I disable my tests for non-appstream versions of Python. I suppose that's tolerable. Is there a version of the Github Action that doesn't have particular dependencies on new-ish versions Python or glibc? I remember there used to be a bash uploader?

[spalmurray]

I believe v3 and earlier use our bash uploader. That said, the bash uploader is no longer supported so I can't recommend you use it.

Another solution that may work for you is moving the coverage reports (upload/download artifact) to another runner that does have a supported glibc version. I believe we do this in some cases internally.

[ktbarrett]

Using use_pypi: true requires that pip is available in the environment? Also going to guess it assumes it can be called directly, which is not true for many environments. That feature should be creating a virtualenv and ensuring pip itself.

[spalmurray]

Yes looks like that is true. I agree that it should do both of those things. I will make an issue for that

[spalmurray]

Going to close this as I think it's fair to say we won't fix this. The use-pypi thing is actionable separately