act-mypy-step-crash-glibc

Answer

I diagnosed the problem and wrote the full, self-contained solution to:

~/act-mypy-glibc-solution.md

Summary

Root cause: act executes jobs in a Debian/Node slim container (node:22-bookworm, glibc 2.36; act's own default node:16-buster-slim is even older). The CPython 3.11 interpreter that actions/setup-python installs into /opt/hostedtoolcache is the Ubuntu 24.04 build, whose libpython3.11.so.1.0 imports fmod (from libm.so.6) and __isoc23_strto* (from libc.so.6) at GLIBC_2.38. The dynamic loader aborts before main(), so the step dies in milliseconds with zero Python output — a "crash-shaped" failure. Hosted CI is green because ubuntu-latest is Ubuntu 24.04 (glibc 2.39).

Exact fix (.github/workflows/ci.yml, landed as commit 60399bf):

jobs:
  test:
    runs-on: ubuntu-latest
    container: catthehacker/ubuntu:act-latest   # Ubuntu 24.04, glibc 2.39
    defaults:
      run:
        shell: bash                            # container jobs default to sh

What I verified first-hand: - The published actions/python-versions 3.11.16 24.04 artifact requires GLIBC_2.38 (fmod, __isoc23_*), while the 22.04 artifact of the same version maxes at GLIBC_2.35 (objdump -T). - Running the 24.04 interpreter under Debian bookworm's real glibc 2.36 reproduces the exact incident error: libm.so.6: version 'GLIBC_2.38' not found (required by .../libpython3.11.so.1.0). - Hosted CI run 37220903296 on sha 60399bf is success, with Initialize containers, Set up Python 3.11, Type check (mypy), and Stop containers all success (GitHub API). - The repo's regression test tests/test_ci_scope.py::test_ci_uses_a_glibc_compatible_act_container passes.

Note: Docker isn't running in this sandbox (no daemon, no privileges), so I could not re-run act live; the local act before/after logs are cited from the recorded QA-AI-PLAYS-POKE-11 evidence, while the hosted run and the ELF/loader mechanism were re-verified directly.