Autobump tokamax pin

[vanbasten23]

Description

Execution workflow:

1. Schedule/manual → the pipeline's single step runs bootstrap_tokamax.sh

It sets TOKAMAX_VERSION, TOKAMAX_PREVIOUS_VERSION, VLLM_COMMIT_HASH as meta-data, uploads four yml documents, and exits. No build, no tests yet.

2. build_docker ×2 (pipeline_build.yml, one per TPU generation — build_docker_tpu6e and build_docker_tpu7x, defined in .buildkite/pipeline_build.yml)

This is setup_docker_env.sh's build path:

• reads TOKAMAX_VERSION from meta-data
• seds requirements.txt
• appends -tkmx to CACHE_TAG
• builds
• runs verify_image_tokamax
• pushes to the CI registry.

3. Every TPU test step (pipeline_jax.yml, v6e + v7x)

run_in_docker.sh → setup_environment again, this time the pull path (USE_PREBUILT_IMAGE=1, run_in_docker.sh): recomputes the same CACHE_TAG from the same meta-data, pulls, and verify_image_tokamax confirms the right image arrived.

4. *_tpu_test_notification per group: check test result.

5. - wait: ~ in integration_tokamax_promote.yml — passes only if everything above passed.

6. promote_tokamax: pushes the bump to main.

Comparison tokamax pin with vLLM pin update:

• tokamax_promote.yml vs integration_promote.yml
• update_tokamax_pin.sh vs update_lkg_version.sh
• bootstrap_tokamax.sh vs the tpu-vllm-integration branch of bootstrap.sh
• requirements.txt (tokamax==) vs .buildkite/vllm_lkg.version

Tests

CI

Checklist

Before submitting this PR, please make sure:

• I have performed a self-review of my code.
• I have necessary comments in my code, particularly in hard-to-understand areas.
• I have made or will make corresponding changes to any relevant documentation.

[github-actions]

Description

Start with a short description of what the PR does and how this is a change from
the past.

The rest of the description includes relevant details and context, examples:

• why is this change being made,
• the problem being solved and any relevant context,
• why this is a good solution,
• some information about the specific implementation,
• shortcomings of the solution and possible future improvements.

If the change fixes a Github issue, please include a link, e.g.,:
FIXES: #123456

Tests

Please describe how you tested this change, and include any instructions and/or
commands to reproduce.

Checklist

Before submitting this PR, please make sure:

• I have performed a self-review of my code.
• I have necessary comments in my code, particularly in hard-to-understand areas.
• I have made or will make corresponding changes to any relevant documentation.