Description
Every CI job that reaches install_minio fails at that step:
Installing MinIO...
curl: (22) The requested URL returned error: 410
##[error]Process completed with exit code 22.
.github/workflows/util/install-spark-deps.sh downloads the MinIO server and client binaries from dl.min.io:
curl -fsSL -o /usr/local/bin/minio https://dl.min.io/server/minio/release/linux-amd64/minio
curl -fsSL -o /usr/local/bin/mc https://dl.min.io/client/mc/release/linux-amd64/mc
MinIO has taken its community binary distribution off dl.min.io. Both URLs now return HTTP 410 Gone, as do the archive/ subpaths and the old dl.minio.io host. -f makes curl exit non-zero on the 410 and set -e fails the step, so tpc-test-ubuntu and the celeborn / uniffle / OOM / random-kill jobs that call setup_minio all go red regardless of what a PR changed. velox_backend_x86.yml is the only workflow that calls these helpers.
This is the same upstream event that broke Paimon CI (apache/paimon#9780), but a different surface. Paimon pulls minio/minio as a Docker image through testcontainers and fixed it by qualifying the name to quay.io/minio/minio. Gluten runs minio server and mc as standalone binaries, so the registry rename does not apply here; the binary download endpoint is what is gone.
Fix
Pull the pinned release assets from GitHub instead. One wrinkle: minio/minio's latest release ships no assets, so the server has to pin to the last release that still carries them.
- server:
RELEASE.2025-09-07T16-13-09Z (latest with assets)
- client:
RELEASE.2025-08-13T08-35-41Z
Both were confirmed to download anonymously; the server asset is a valid 110 MB x86-64 ELF binary. linux-amd64 is unchanged, matching the one x86 workflow that uses these helpers.
Filed alongside the PR that fixes it.
Description
Every CI job that reaches
install_miniofails at that step:.github/workflows/util/install-spark-deps.shdownloads the MinIO server and client binaries fromdl.min.io:MinIO has taken its community binary distribution off
dl.min.io. Both URLs now return HTTP 410 Gone, as do thearchive/subpaths and the olddl.minio.iohost.-fmakes curl exit non-zero on the 410 andset -efails the step, sotpc-test-ubuntuand the celeborn / uniffle / OOM / random-kill jobs that callsetup_minioall go red regardless of what a PR changed.velox_backend_x86.ymlis the only workflow that calls these helpers.This is the same upstream event that broke Paimon CI (apache/paimon#9780), but a different surface. Paimon pulls
minio/minioas a Docker image through testcontainers and fixed it by qualifying the name toquay.io/minio/minio. Gluten runsminio serverandmcas standalone binaries, so the registry rename does not apply here; the binary download endpoint is what is gone.Fix
Pull the pinned release assets from GitHub instead. One wrinkle:
minio/minio's latest release ships no assets, so the server has to pin to the last release that still carries them.RELEASE.2025-09-07T16-13-09Z(latest with assets)RELEASE.2025-08-13T08-35-41ZBoth were confirmed to download anonymously; the server asset is a valid 110 MB x86-64 ELF binary.
linux-amd64is unchanged, matching the one x86 workflow that uses these helpers.Filed alongside the PR that fixes it.