Unify cu128/cu130 PR build jobs with docker/build_wheel.py

[swahtz]

Context

#731 introduced docker/build_wheel.py + docker/Dockerfile.wheel — a single scripted recipe for production wheels — and converted publish.yml and nightly-publish.yml to use it. The PR build-and-test workflows (.github/workflows/cu128.yml, .github/workflows/cu130.yml) still carry their own duplicated inline build logic (~90 lines each of toolchain/CMake/uv/torch setup) in their fvdb-build jobs.

Converting them would complete the unification and make PR CI build exactly what publish builds. The wheel part converts cleanly — the script already supports --cuda-arch-list, --version-mode none, and --skip-auditwheel — and the downstream fvdb-unit-test / fvdb-docs-test jobs are unaffected (they consume the wheel artifact). But there are three complications that need decisions/work, which is why this was split out of #731.

Complications

1. Deliberate environment difference (policy decision)

The PR builds use Ubuntu 22.04 + gcc from the ubuntu-toolchain PPA; the publish recipe uses Rocky Linux 8 + gcc-toolset. Converting removes the only CI coverage of the Ubuntu build path (which the README and dev Dockerfile recommend to users), in exchange for PRs testing exactly what gets published. Decide whether Ubuntu build coverage is a feature to keep (e.g. keep one lane on the old path, or add an OS build-arg to the Dockerfile) or an accident of history.

2. gtests/benchmarks artifact export (the main work)

fvdb-build runs ./build.sh wheel verbose gtests benchmarks and tars the whole build/ tree so the GPU runner can run native ctest binaries. Dockerfile.wheel only exports dist/. Needed:

• A --build-tests-style flag on build_wheel.py mapping to the gtests benchmarks build modifiers (FVDB_BUILD_TESTS/FVDB_BUILD_BENCHMARKS).
• A second export stage (or extended export stage) that also copies out build/ (multi-GB).
• A WORKDIR build-arg: CTestTestfile.cmake embeds absolute paths. Today build and test containers both mount the workspace at /__w/fvdb-core/fvdb-core, so paths match; a docker build at /workspace/fvdb-core would break ./build.sh ctest on the test runner unless CI can set the in-image build path to match the runner workspace.

3. Viewer dependency difference

The PR builds pip install the nanovdb_editor spec (via .github/scripts/get_viewer_dependency.py) before building; the publish recipe does not. So PR wheels and published wheels genuinely differ today. Either add an optional hook to the script (e.g. --extra-pip-spec), or accept aligning PR builds with publish behavior — which changes what the GPU test jobs exercise.

Notes

• PR builds run on fresh EC2 instances, so Docker layer caching is a wash vs. today's per-run toolchain install.
• The gtests currently run against binaries built with the PR arch list (8.9+PTX) on g6.xlarge (L4, compute 8.9); this carries over unchanged via --cuda-arch-list.

🤖 Generated with Claude Code