Update runtime dependency versions, validate Docker build compatibility, and drive the Docker image PR workflow.
Input package versions: $VERSION
Arguments ($VERSION): a list of pinned package versions, such as "sglang==0.5.9
vllm==0.10.1 torch==2.10.1"
The Dockerfile produces two image variants from a single file:
ghcr.io/inclusionai/areal-runtime:{tag}-sglang — SGLang inference backendghcr.io/inclusionai/areal-runtime:{tag}-vllm — vLLM inference backendBoth variants share the same base image (lmsysorg/sglang:…) and identical layers up to
STAGE 3. Only ARG VARIANT (declared late for cache efficiency) controls which
inference backend is installed via --extra ${VARIANT}.
The latest tag always points to the sglang variant.
Validate versions. Update the version requirements in @pyproject.toml according to the input. Validate that the provided versions exist in the pip registry. Otherwise, exit and raise an error report to the user. Keep other dependency versions unchanged in this step.
Check upstream dependency compatibility. For the following packages, browse the GitHub repo and check for dependency version mismatches with AReaL:
https://github.com/sgl-project/sglang/blob/v${version}/python/pyproject.tomlhttps://github.com/vllm-project/vllm/blob/v${version}/pyproject.tomlFocus on the verions of following packages in particular:
Resolve dependency conflicts and report to user.
If there's no inconsistency between the above packages, and it only conflicts with AReaL, update AReaL's version.
If the above packages have mutual conflict, summarize and report to user, then you MUST ask the user for resolution.
Output format:
Summary
---
Updated Packages (no actions required):
- ${name}, ${packageA} requires ${packageAVersion}, ${packageB} requires ${packageBVersion}, AReaL specified ${version}, updated to ${version}
- ...
---
Mismatched Packages (need to resolve):
- ${name}, ${packageA} requires ${packageAVersion}, ${packageB} requires ${packageBVersion}
- ...
Update @pyproject.toml according to the user's conflict resolution. You may use
override-dependencies in [tool.uv] to force-pin versions where needed. Remember
that sglang and vllm are declared as conflicting extras — never install both.
Validate that the conflicts in step 3 have been all resolved. If not, return to step 3 and you MUST ask the user again.
Lock dependencies. Run uv lock to regenerate uv.lock. If errors occur, return
to step 3 — you must ask the user for resolution before modifying and trying again.
Update the Dockerfile if needed. The Dockerfile uses only ARG VARIANT (no
ARG BASE_IMAGE) to select between sglang and vllm. All layers before the VARIANT
declaration are shared between both variants for Docker cache efficiency.
Only modify the Dockerfile if the base image, system packages, or build steps need to
change (e.g., new base image URL, new CUDA version). Do NOT modify it just for
pyproject.toml version bumps — uv pip install -r pyproject.toml handles that
automatically.
Create a PR and trigger CI. Load the create-pr skill to create the PR, then
trigger the CI workflow manually via .github/workflows/build-docker-image.yml.
The docker build CI builds both sglang and vllm images, then automatically triggers testing on each. Debug until the overall workflow succeeds.
If you encounter issues that cannot be resolved, ask the user for help.