Update release pipeline post PyTorch 2.8.0 update

[youkaichao]

Purpose

Redo #23960 in an upstream branch so that we can trigger build with custom env vars.

Test Plan

Test Result

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[gemini-code-assist]

Code Review

This pull request updates the release pipeline to use CUDA 12.9, which is necessary for the PyTorch 2.8.0 update. The changes correctly update the CUDA versions and corresponding build identifiers in the Buildkite pipeline configuration. The wheel upload script has also been modified to handle CUDA 12.9 as the new default version for publishing wheel indices. My review includes suggestions to improve the robustness of the wheel upload script to make it more maintainable and prevent potential issues in future releases.

[gemini-code-assist]

The current if/elif/else structure for determining whether to upload index files is fragile. It assumes that any wheel not matching cu126 or cu128 is the default cu129. This could lead to incorrect behavior if other wheel versions are added to the build pipeline in the future.

Using a case statement would make this logic more explicit and robust. It clearly defines the action for each known wheel type and can provide a warning for unexpected versions, preventing silent failures in the release process.

Suggested change

	if [[ $normal_wheel == *"cu126"* ]]; then
	# if $normal_wheel matches cu126, do not upload the index.html
	echo "Skipping index files for cu126 wheels"
	elif [[ $normal_wheel == *"cu128"* ]]; then
	# if $normal_wheel matches cu128, do not upload the index.html
	echo "Skipping index files for cu128 wheels"
	else
	# only upload index.html for cu128 wheels (default wheels)
	# only upload index.html for cu129 wheels (default wheels) as it
	# is available on both x86 and arm64
	aws s3 cp index.html "s3://vllm-wheels/$BUILDKITE_COMMIT/vllm/index.html"
	aws s3 cp "s3://vllm-wheels/nightly/index.html" "s3://vllm-wheels/$BUILDKITE_COMMIT/index.html"
	fi
	case "$normal_wheel" in
	*cu129*)
	# only upload index.html for cu129 wheels (default wheels) as it
	# is available on both x86 and arm64
	aws s3 cp index.html "s3://vllm-wheels/$BUILDKITE_COMMIT/vllm/index.html"
	aws s3 cp "s3://vllm-wheels/nightly/index.html" "s3://vllm-wheels/$BUILDKITE_COMMIT/index.html"
	;;
	*cu126*|*cu128*)
	# if $normal_wheel matches cu126 or cu128, do not upload the index.html
	echo "Skipping index files for $normal_wheel wheels"
	;;
	*)
	echo "WARNING: Unhandled wheel version for index upload: $normal_wheel. Not uploading index."
	;;
	esac

[gemini-code-assist]

Similar to the block above, this if/elif/else structure is fragile. It implicitly assumes any wheel not matching cu126 or cu128 is the default cu129 for which the nightly index should be updated.

Refactoring to a case statement will make the logic more robust and maintainable, explicitly handling known cases and warning about unknown ones. This is important for the stability of the release pipeline.

Suggested change

	if [[ $normal_wheel == *"cu126"* ]]; then
	# if $normal_wheel matches cu126, do not upload the index.html
	echo "Skipping index files for cu126 wheels"
	elif [[ $normal_wheel == *"cu128"* ]]; then
	# if $normal_wheel matches cu128, do not upload the index.html
	echo "Skipping index files for cu128 wheels"
	else
	# only upload index.html for cu128 wheels (default wheels)
	# only upload index.html for cu129 wheels (default wheels) as it
	# is available on both x86 and arm64
	aws s3 cp index.html "s3://vllm-wheels/nightly/vllm/index.html"
	fi
	case "$normal_wheel" in
	*cu129*)
	# only upload index.html for cu129 wheels (default wheels) as it
	# is available on both x86 and arm64
	aws s3 cp index.html "s3://vllm-wheels/nightly/vllm/index.html"
	;;
	*cu126*|*cu128*)
	# if $normal_wheel matches cu126 or cu128, do not upload the index.html
	echo "Skipping index files for $normal_wheel wheels"
	;;
	*)
	echo "WARNING: Unhandled wheel version for nightly index upload: $normal_wheel. Not uploading index."
	;;
	esac

[nWEIdia]

I can see this PR pushed a new aarch64 image from the 2nd last commit of this branch, great! (See: https://gallery.ecr.aws/q9t5s3a7/vllm-release-repo 43a6f63d0860ef2f545122332d7a377e99010838-aarch64)
Do you know why the top commit did not generate a new aarch64 build?

[youkaichao]

Do you know why the top commit did not generate a new aarch64 build?

because I don't trigger release build for the latest commit.

[nWEIdia]

Looks great to me, thanks!

[huydhn]

Stamped! Retrying on #23960 seems to work for me too to avoid timing out in the release build https://buildkite.com/vllm/release/builds/7828. So both PR(s) are fine I think

[youkaichao]

Retrying on #23960 seems to work for me too to avoid timing out in the release build

yeah that's because I manually triggered a 10 hour build, now the compilation cache is populated, and later release build can be much faster.