fzyzcjy 7889ed4091 Cover the ray x rpc worker comm path in CI ...

`--cluster-backend ray` accepts both `--worker-comm-backend ray` and
`rpc`, but every e2e test takes the default, which is `ray`. The rpc
wiring under a ray cluster -- `_ServeActorManager`, the per-worker http
server, and the `RayObjectStore(frees_objects=True)` branch it selects --
therefore has no e2e coverage at all: it is only ever exercised by hand
before a multi-deployment run, so a regression in it stays invisible
until someone deploys.

Generalize the gsm8k short scenario over the comm backend and add a
second registration that runs it with `--worker-comm-backend rpc`. The
new file is a shell: its module body is one `register_cuda_ci` call, and
it loads the base test by path inside `__main__`, because the base
module name contains dots and cannot be imported by name.

The scenario takes the caller's `__file__` so the two variants land in
separate wandb projects, and emits nothing when the backend is `ray`, so
the base variant's command line is unchanged and a red base stays
attributable to the base.

The rpc variant registers CUDA only. The mi350 lane is expensive and the
comm backend is not hardware specific, so one lane is enough to catch a
regression.

2026-09-02 18:44:32 +08:00

..

scripts/release

release: miles version release workflow (#2538)

2026-08-14 19:57:37 -07:00

workflows

Cover the ray x rpc worker comm path in CI

2026-09-02 18:44:32 +08:00

CODEOWNERS

refactor: move the FSDP backend out of experimental (#2272)

2026-08-07 20:08:54 -07:00