build(cuda): Add CUDA_VERSION build arg to adapters dockerfile

[bdice]

Summary

We would like to make it easier to configure the CUDA version used in building Velox containers.

This PR adds a CUDA_VERSION build arg to the adapters stage in centos-multi.dockerfile which allows overriding the CUDA version at build time. As before, it defaults to 12.9.

This mirrors the approach in prestodb/presto#27074.

[netlify]

✅ Deploy Preview for meta-velox canceled.

Name	Link
🔨 Latest commit	81adc2d
🔍 Latest deploy log	https://app.netlify.com/projects/meta-velox/deploys/6983b3f798d903000831a400

[bdice]

This environment variable is read by bash /setup-centos-adapters.sh install_cuda in the next step.

[karthikeyann]

Looks good to me.
@czentgr to review this PR since it adds a new ARG to docker image.

[zoltan]

LGTM

[meta-codesync]

@peterenescu has imported this pull request. If you are a Meta employee, you can view this in D92988821.

[meta-codesync]

@jainxrohit merged this pull request in 9ea2545.

[kgpai]

@bdice Folks looks like the docker publish scripts arent working : https://github.com/facebookincubator/velox/actions/runs/21961775674/job/63448645977 so your cuda version will not be updated.
Can you folks fix the script ? I am going to revert this change in the meantime - We can reland this after the fix.

[karthikeyann]

@kgpai could you elaborate, what is the issue with the script?

[bdice]

Looks like this:

ERROR: ghcr.io/facebookincubator/velox-dev:buildx.build.warnings-arm64: not found

Nothing I changed here is arm64-specific. Do the images build successfully without this change? It’s not a network error or something temporary?

[karthikeyann]

@kgpai Triaged the issue.
This error comes because of buildx.build.warnings artifact appears from "Build ci Image on arm64" job, and it is generated from
https://github.com/facebookincubator/velox/actions/runs/21961775674/job/63440855278#step:8:321

It comes from

          "filename": "scripts/docker/centos-multi.dockerfile",
              "line": 167

which is

velox/scripts/docker/centos-multi.dockerfile

Line 167 in 6dbd604

ENV LD_LIBRARY_PATH="/usr/local/lib:/usr/local/lib64:$LD_LIBRARY_PATH"

This seems to be unrelated to this line change, only connection is this PR changes the same file scripts/docker/centos-multi.dockerfile but different line.

Fix could be either

ENV LD_LIBRARY_PATH="/usr/local/lib:/usr/local/lib64:${LD_LIBRARY_PATH:-}"

or

ENV LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64

Or Suggested alternative fix in issue #16386

[bdice]

To add to @karthikeyann's analysis -- the Dockerfile warning is the trigger, but the reason it breaks the build is a bug in the "Export digests" step of docker.yml. The jq filter iterates over all top-level keys in the bake metadata and creates a file for each one. When buildx emits a buildx.build.warnings key in the metadata (due to the LD_LIBRARY_PATH lint warning), that key gets turned into a file alongside the real targets (adapters, centos9, pyvelox). Then the merge job's for file in * loop tries to create a multi-arch manifest for it and fails.

Fixing the Dockerfile warning resolves the immediate issue, but the jq filter should also be hardened so that any future buildx metadata key (e.g., buildx.build.ref, buildx.build.provenance) doesn't cause the same failure. The real image targets all have an image.name field in their metadata value -- the filter could select only entries where that field exists:

'def skip: ["ubuntu", "fedora"];
  . | to_entries[] | select(.value | has("image.name")) |
  .key | split("-")[0] |
  if . as $name | skip | index($name) != null then empty else . end'

[kgpai]

Cool Thank you @bdice & @karthikeyann ; Not sure when these warnings started appearing in the digest , but as suggested it makes sense to use ld.conf and also fix the jq script.