CI: Use manylinux_2_28 for wheels to fix h5py/HDF5 build failure

[Copilot]

The build_wheels job was pinned to manylinux2014 (CentOS 7), which provides HDF5 1.8.12 via yum — too old for modern h5py (requires ≥ 1.10.7). This caused wheel test installs to fail when pip fell back to building h5py from source.

Changes

• .github/workflows/build_wheels.yml
  • CIBW_MANYLINUX_X86_64_IMAGE: "manylinux2014" → "manylinux_2_28" — aligns with the existing pyproject.toml setting that was being overridden
  • CIBW_BEFORE_ALL_LINUX: replaced CentOS 7 vault/yum mirror hack with dnf install -y epel-release; dnf install -y hdf5-devel openblas-devel, consistent with the [tool.cibuildwheel.linux] config in pyproject.toml

# Before
CIBW_MANYLINUX_X86_64_IMAGE: "manylinux2014"
CIBW_BEFORE_ALL_LINUX: "sed -i -e 's/mirrorlist/#mirrorlist/g' ... ; yum install -y hdf5-devel openblas-devel"

# After
CIBW_MANYLINUX_X86_64_IMAGE: "manylinux_2_28"
CIBW_BEFORE_ALL_LINUX: "dnf install -y epel-release; dnf install -y hdf5-devel openblas-devel"

macOS jobs are unaffected. Refs failing job: https://github.com/Green-Phys/green-igen/actions/runs/24995436842/job/73191102734

Original prompt

Repository: Green-Phys/green-igen

Goal: Fix failing GitHub Actions wheel build/test job by updating the Linux cibuildwheel configuration to use a modern manylinux image and matching package installation commands, avoiding HDF5 1.8.12 which breaks h5py build.

Failure context:

• Failing Actions job URL: https://github.com/Green-Phys/green-igen/actions/runs/24995436842/job/73191102734
• In job logs, during cibuildwheel test install (pip install /tmp/cibuildwheel/repaired_wheel/green_igen-0.2.7-...whl), pip attempts to build h5py and fails with:
  "This version of h5py requires HDF5 >= 1.10.7 and != 1.12.0 (got version (1, 8, 12) ...)"
• This comes from using a manylinux2014 image + yum-provided hdf5-devel (CentOS 7) which is too old.

Current workflow definition:

• File: .github/workflows/build_wheels.yml (ref 68d1f32)
• Job build_wheels uses pypa/cibuildwheel@v2.19.0 and sets:
  • CIBW_MANYLINUX_X86_64_IMAGE: "manylinux2014"
  • CIBW_BEFORE_ALL_LINUX: uses sed to change CentOS mirrorlist to vault + yum install hdf5-devel ...
• Repo already has cibuildwheel config in pyproject.toml setting manylinux-x86_64-image = "manylinux_2_28" and Linux before-all using dnf install ... hdf5-devel openblas-devel.

Requested change:

1. Update .github/workflows/build_wheels.yml job build_wheels to stop overriding to manylinux2014.
   • Prefer using manylinux_2_28 consistently with pyproject.toml.
   • Set CIBW_MANYLINUX_X86_64_IMAGE: "manylinux_2_28" (or remove the override entirely if cibuildwheel will pick it from pyproject.toml; but ensure result is manylinux_2_28).
2. Update CIBW_BEFORE_ALL_LINUX for the build_wheels job to use dnf installation compatible with manylinux_2_28, e.g.:
   • dnf install -y epel-release; dnf install -y hdf5-devel openblas-devel
   • Remove the CentOS vault/yum repo editing, since it is specific to CentOS 7/manylinux2014 and causes old HDF5.
3. Ensure the change does not affect macOS jobs.
4. Keep CI stable across cp38-cp312 builds.

Deliverables:

• Create a PR with the workflow update.
• PR title suggestion: "CI: Use manylinux_2_28 for wheels to fix h5py/HDF5 build failure".
• In PR description, reference the failing job URL and explain that HDF5 1.8.12 from manylinux2014 breaks h5py, and that manylinux_2_28 provides newer HDF5.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for this failing job. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: The job fails while testing the built wheel because pip install ...green_igen-0.2.7...whl tries to install h5py, and h5py falls back to building from source inside the manylinux container. That build aborts with:

This version of h5py requires HDF5 >= 1.10.7 ... (got version (1, 8, 12))

So the environment is providing HDF5 1.8.12, which is too old for the h5py version pip is attempting to build.

Fix (recommended): ensure a modern HDF5 + avoid source builds of h5py during wheel testing

In your workflow .github/workflows/build_wheels.yml the Linux job sets CIBW_MANYLINUX_X86_64_IMAGE: "manylinux2014" and installs hdf5-devel via yum. On CentOS 7 (manylinux2014), that typically yields HDF5 1.8.x, which triggers this failure.

You already have a better configuration in pyproject.toml:

• manylinux-x86_64-image = "manylinux_2_28"
• Linux before-all uses dnf install ... hdf5-devel

But the workflow overrides it back to manylinux2014 for the first job. Remove that override (or switch it to 2_28), and install HDF5 via dnf to get a sufficiently new HDF5.

Patch suggestion: update Linux wheel build to manylinux_2_28 and dnf HDF5

Edit .github/workflows/build_wheels.yml (ref 68d1f3257426e822c714225be051e05d143d440f) to stop forcing manylinux2014 and use a 2_28 image, e.g.:

      - name: Build wheels
        uses: pypa/cibuildwheel@v2.19.0
        env:
          CIBW_BUILD: cp38-* cp39-* cp310-* cp311-* cp312-*
          CIBW_ARCHS: ${{ matrix.plat.arch }}

          # Use a modern manylinux image so system HDF5 is new enough for h5py
          CIBW_MANYLINUX_X86_64_IMAGE: "manylinux_2_28"

          # Install deps with dnf (works for manylinux_2_28)
          CIBW_BEFORE_ALL_LINUX: "dnf install -y epel-release; dnf install -y hdf5-devel openblas-devel"

And remove the current CentOS vault/yum-based CIBW_BEFORE_ALL_LINUX line that installs the old hdf5-devel from CentOS 7 repos (that’s where the HDF5 1.8.12 is coming from).

Optional hardening: force binary wheels for h5py during the “pip install wheel” test

Even with newer HDF5, you can prevent accidental source builds in the test install step by adding:

CIBW_TEST_EXTRAS: ""
CIBW_TEST_REQUIRES: "pytest"
CIBW_TEST_COMMAND: "python -c \"import h5py; ...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>

[egull]

Gaurav, I'm assigning you as a reviewer. I think the code is basically ok but uses a not-yet-merged interface upstream. Once that's merged to main, everything should pass and we can merge this.

[gauravharsha]

I think this is harmless to merge - the tests that are failing will pass once we have a release for green-mbtools, but perhaps we can fix that too by using the GitHub source instead of PyPI. What do you think?

[egull]

Agree. We can either do that or just wait. Likely master of github source will be best as we continue working with it and mbtools. I will revise.