build(deps): Ray 2.56.0 image base locks (base-only)#833
Merged
Conversation
Aydin-ab
force-pushed
the
deps/ray-2.56.0-recompile
branch
from
bdb7bbf to
1c2c64d
Compare
Aydin-ab
changed the title
Add the ray2560 py311/py312 bundles and attach them to the base ray_depset compile entry (dual-version — ray2551 kept for rollback), and commit the generated ray_2.56.0_img_py311/py312 base locks. Fix the soruce_depset typo. ray_llm stays ray2551-only: Ray's 2.56.0 LLM deplock isn't published upstream yet (fetch 404s), so rayllm_2.56.0 + the LLM templates are a follow-up. Per- template expand entries stay on 2551 — each template's bump PR repoints its own entry (base-first rollout). Claude-Session: https://claude.ai/code/session_01HEiVRurDkXnrLAyCduiLdH Signed-off-by: Aydin Abiar <aydin@anyscale.com>
Aydin-ab
force-pushed
the
deps/ray-2.56.0-recompile
branch
from
1c2c64d to
0b82663
Compare
Aydin-ab
changed the title
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
The full-tree update_deps.sh run in f7d85fd recompiled the 2.55.1 image locks from a clobbered base lock (the 2.56.0 base lock overwrote the 2.55.1 one in the shared /tmp/ray-deps scratch dir, since the fetched filename was keyed only on Python minor, not Ray version). That floated fastapi 0.121.0->0.133.0, pandas 1.5.3->2.3.3, and pulled in mmh3. Restore both ray_2.55.1_img_py{311,312}.lock to match main. The scratch filename collision itself is fixed separately by namespacing the fetched base/LLM/constraints files by Ray version. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ratch collisions
update_deps.sh fetched each Ray base input into /tmp/ray-deps/ under a
filename keyed only on Python minor (+CUDA), not Ray version. When a
single run compiled multiple Ray versions sharing a Python minor (e.g.
ray2551_py311 + ray2560_py311), their pre_hooks clobbered each other's
scratch file, so one version's base lock fed the other's compile (see
prior 2.55.1 drift revert).
Namespace the local dest by ${RAY_VERSION} while keeping the remote
upstream filename version-agnostic (that's what the ray-<ver> tag
serves): split REMOTE_FILE vs LOCK_FILE/DEST_FILE in the lock/constraints
fetchers and update the matching requirements: paths in
template.depsets.yaml.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Guarantees a hermetic scratch dir between runs so stale fetched base locks can't linger. Belt-and-suspenders on top of the per-version filename namespacing: pre_hooks re-fetch everything they need, and a clean dir makes a genuinely-missing upstream file fail loudly instead of silently reusing a stale copy. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
elliot-barn
approved these changes
Jul 2, 2026
Aydin-ab
added a commit
that referenced
this pull request
Jul 2, 2026
…831) The `/template` Ray-bump automation had no per-template depset recipe, so the Ray 2.56.0 batch behaved inconsistently. This teaches the skill (and the cursor preflight) how depsets interact with a bump. **Docs + preflight only — no CI or lockfile changes** (those are #834 / #835 / #833). ## Why - **No per-template depset recipe** — `bump-ray-version.md` only pointed at the whole-repo *batch* `upgrade-dependencies.md`; nothing covered no-lock templates or how to read the repo-global `check-depsets` gate. - **#819 was a workflow drop** — the cleanest 2.56.0 PR stuck because the agent opened a draft and never dispatched `/test-template`. - **`.cursor` was never the block** — `raydepsets` bundles `uv` and recompiled fine in the cursor env; but preflight never smoke-tested the toolchain, so a real breakage would only surface mid-bump. ## Changes - `bump-ray-version.md` — per-template depset recipe (no-lock vs has-lock), batch-vs-per-template preamble, `check-depsets`-is-repo-global note, explicit **Done criteria**. - `upgrade-dependencies.md` / `dependencies.md` — label the human/batch path; document the gate's collateral behavior. - `.cursor/preflight.sh` — depset-toolchain smoke test (fail at preflight, not mid-bump). ## Testing `pre-commit` on changed files passed. Docs/preflight only — no runtime impact; validated end-to-end by retriggering `template-updater` against the fixed skill. --------- Signed-off-by: Aydin Abiar <aydin@anyscale.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The base half of the Ray 2.56.0 depset bump: the
ray2560bundle + the two generated image base locks. Per-templateexpandentries stay on 2551 — each template's own bump PR repoints its entry (base-first rollout).What
ray2560_py311_cu128/ray2560_py312_cu128bundles, attached to the baseray_depsetcompile entry alongsideray2551(dual-version → 2.55.1 base locks kept for rollback).ray_2.56.0_img_py311/py312.lock(compiled from Ray 2.56.0's publishedray_imglocks viaupdate_deps.sh).soruce_depset→source_depsettypo (langchain entry).LLM base deferred (upstream not ready)
ray_llmstaysray2551-only: Ray's 2.56.0 LLM deplock isn't published yet (deplocks/llm/…404s).rayllm_2.56.0+ the LLM templates (langchain, audio, multi_agent, llm_batch_inference_vision, …) are a follow-up once Ray ships it.Notes
expandentry + regenerate their lock + bump their image together.check-depsetsmay flag ambient drift on the untouched 2551 locks on a full recompile; it's being disabled separately (ci(depsets): temporarily disable the check-depsets gate #836), and ci(depsets): scope check-depsets to changed locks + retry transient errors #834 re-enables a scoped version later.