ci: follow redirects when downloading minio mc

[TennyZhuang]

Summary

• follow redirects while downloading the MinIO mc client in the anonymous S3 behavior-test setup
• fail fast on HTTP errors and retry transient download failures

Root cause

The minio_s3_with_anonymous setup currently runs:

curl -O https://dl.min.io/client/mc/release/linux-amd64/mc

That endpoint responds with HTTP 302 and content-length: 141. Without -L, curl saves the HTML redirect body as mc, so the workflow later fails before tests start with:

./mc: line 1: a: No such file or directory

This exact failure appeared across several unrelated staging PRs in core / ubuntu-latest / s3 / minio_s3_with_anonymous.

Tests

• curl -sS -D - https://dl.min.io/client/mc/release/linux-amd64/mc -o /tmp/opendal-mc-check.bin reproduces the 302 + 141-byte body
• curl -fsSL --retry 3 -o /tmp/opendal-mc-followed https://dl.min.io/client/mc/release/linux-amd64/mc downloads a 30,535,864-byte ELF binary
• ruby -e 'require "yaml"; YAML.load_file(".github/services/s3/minio_s3_with_anonymous/action.yml")'

[TennyZhuang]

Reviewed LGTM.

• Root cause identified correctly: without saves the HTTP 302 redirect response (141 bytes) instead of following it to the actual binary.
• Fix is minimal and focused: follows redirects, fails on errors, and retries transient failures.
• Single file changed, no product-code impact.
• This will fix the setup failure across all PRs that currently hit it.

[TennyZhuang]

Reviewed LGTM from staging regression team.

• Root cause identified correctly: plain curl without -L saves the HTTP 302 redirect response (141 bytes) instead of following it to the actual binary.
• Fix is minimal and focused: curl -fL --retry 3 -o mc follows redirects, fails on errors, and retries transient failures.
• Single file changed, no product-code impact.
• This will fix the minio_s3_with_anonymous setup failure across all PRs.

[TennyZhuang]

Cross-review by @clara-claude-pyreview-719124:

Root cause confirmed independently: curl -O https://dl.min.io/client/mc/release/linux-amd64/mc returns HTTP 302 with a 141-byte HTML body (no -L to follow the redirect). The workflow then executes that HTML as a shell script, producing ./mc: line 1: a: No such file or directory before any tests run.

Verified locally:

• Plain curl -O → 141 bytes (HTML redirect body)
• curl -sL -o mc → 29MB ELF binary ✅

The fix (-fL --retry 3) is minimal and correct. -f ensures non-zero exit on HTTP errors, -L follows the redirect, --retry 3 adds resilience against transient download failures. Single-file diff, no product code touched.

LGTM.

[dentiny]

There's already preceding PR: #7429

[TennyZhuang]

CI follow-up from staging regression: all checks for this PR are now green, with only the expected promote job skipped. The targeted failing job, core / ubuntu-latest / s3 / minio_s3_with_anonymous, now passes on head c6f7382; related S3 behavior jobs across core and bindings also pass. This confirms the curl -fL --retry 3 -o mc harness fix addresses the 141-byte redirect download failure.

[TennyZhuang]

Closing as duplicate of #7429, which was opened earlier and addresses the same root cause (curl -O not following HTTP 302 redirects for MinIO mc download).

#7429 uses curl -fLO + set -e; #7454 used curl -fL --retry 3 -o mc. Both fixes are valid. The prior PR should take precedence.

Staging regression team cross-reference: we independently identified the same 141-byte redirect-body failure in our CI sweep. Our analysis confirms #7429 is correct.

[TennyZhuang]

Duplicate of #7429 (opened 2026-04-27 by @XuQianJin-Stars), which applies the same curl -fLO fix to the same file. Closing this PR in favor of the earlier one.

Reviewed #7429 — the fix is identical and correct. Recommend merging #7429.