Configures install scripts, Dockerfiles, and CI pipelines for new models or environments in RLinf.
Install
mkdir -p .claude/skills/add-install-docker-ci-e2e && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/3336" && unzip -o skill.zip -d .claude/skills/add-install-docker-ci-e2e && rm skill.zipInstalls to .claude/skills/add-install-docker-ci-e2e
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Adds install command in install script, Docker build stage in Dockerfile, and CI jobs for docker build and embodied e2e test when introducing a new model or environment in RLinf. Use when adding a new embodied model (e.g. dexbotic), new env (e.g. maniskill_libero), or new model+env combination that should be installable, dockerized, and tested in CI.Key capabilities
- →Registers new models to install scripts
- →Adds Docker build stages to Dockerfile
- →Injects new CI test jobs
- →Updates installation help menus
How it works
Modifies multiple configuration files including bash install scripts, Dockerfile stages, and CI YAML files to accommodate new model dependencies.
Inputs & outputs
When to use add-install-docker-ci-e2e
- →Adding a new embodied model
- →Setting up CI for new environments
- →Containerizing new model dependencies
About this skill
Add Install, Docker Build, and CI for a New Model or Environment
Use this skill when adding a new model or new environment (or combination) to RLinf so that: (1) users can install it via requirements/install.sh, (2) a Docker image can be built for it (optional), (3) CI runs a Docker build and an end-to-end test.
1. Install script (requirements/install.sh)
-
Register model or env
- New model: add to
SUPPORTED_MODELS(e.g."dexbotic"). - New environment: add to
SUPPORTED_ENVS(e.g."maniskill_libero").
- New model: add to
-
Implement install logic
- New model: add
install_<model>_model()that switches onENV_NAMEand for each supported env: create venv, install common embodied deps, env-specific deps, and the model. Call it from the maincase "$MODEL"(add a newmodel_name)branch that runsinstall_<model>_model). - New env only (no new model): either add a new env branch inside an existing
install_*_model()or addinstall_<env>_env()and call it from the relevant model installers. If the env is used byinstall_env_only, add a branch ininstall_env_onlyfor that env.
- New model: add
-
Help text
print_helpshowsSUPPORTED_MODELSandSUPPORTED_ENVS; no change needed if you only added to those arrays.
See reference.md for exact variable names and code patterns.
2. Dockerfile (docker/Dockerfile)
-
Base image
If the combo needs a different base (e.g. Ubuntu 20 for ROS/Franka), add:FROM <base> AS base-image-embodied-<target>
Otherwise reuse:FROM nvidia/cuda:12.4.1-cudnn-devel-ubuntu22.04 AS base-image-embodied-<target>. -
Build stage
Add a stage:FROM embodied-common-image AS embodied-<target>-image- Single RUN for all installs: If the image installs multiple envs (multiple model+env or venvs), chain every
install.shcall in oneRUNwith&&. Splitting installs across multipleRUNlayers breaks uv’s hardlink mode (UV_LINK_MODE=hardlink), because the cache from the previous layer is not in the same layer for hardlinking. Example:RUN bash requirements/install.sh embodied --venv openvla --model openvla --env maniskill_libero && \thenbash requirements/install.sh embodied --venv openpi --model openpi --env maniskill_libero. - Any asset download/link in the same or a following RUN; then
RUN echo "source \${UV_PATH}/<venv>/bin/activate" >> ~/.bashrcfor default env.
-
Final stage
The last stage isFROM ${BUILD_TARGET}-image AS final-image. ValidBUILD_TARGETvalues are those that have a matching*-imagestage (e.g.reason,embodied-maniskill_libero,embodied-dexbotic-maniskill_libero). Adding a new stage makes the new target valid; no change to the final stage line.
Naming: BUILD_TARGET is typically embodied-<env> (e.g. embodied-maniskill_libero) or embodied-<env>-<model> when one image combines multiple models (e.g. behavior-openvlaoft). Match the pattern used by existing stages.
3. CI: Docker build (.github/workflows/docker-build.yml)
Add a job that builds the new image:
- Job id:
build-embodied-<target>(same<target>as in Dockerfile stage name, e.g.build-embodied-maniskill_libero). - Reuse the same steps as existing jobs: maximize storage, checkout, setup Docker Buildx, then build with
BUILD_TARGET=embodied-<target>,NO_MIRROR=true,outputs: type=cacheonly, and a tag likerlinf:embodied-<target>.
Copy an existing build-embodied-* job and replace the target name. See reference.md.
4. CI: Embodied e2e test (.github/workflows/embodied-e2e-tests.yml)
-
Test config
Add a YAML config undertests/e2e_tests/embodied/(e.g.<env>_<algo>_<model>.yaml). The e2e runner istrain_embodied_agent.pywith--config-name <name>; the config name is the filename without.yaml. -
Workflow job
Add a job (e.g.embodied-<model>-<env>-test):- Checkout.
- Create embodied environment: set
UV_*, any required path env vars (e.g.GR00T_PATH,BEHAVIOR_PATH), thenbash requirements/install.sh embodied --model <model> --env <env>. - Run test:
source .venv/bin/activate, setREPO_PATH, thenbash tests/e2e_tests/embodied/run.sh <config_name>(orrun_async.shif the test is async). Use a reasonabletimeout-minutes. - Clean up:
rm -rf .venv,uv cache prune, and any test-specific cleanup.
Use runs-on: embodied so the job runs on a runner with GPU/datasets. See existing jobs in the file for env vars and step order.
Checklist
- Install script: Model in
SUPPORTED_MODELSand/or env inSUPPORTED_ENVS;install_*function andcase "$MODEL"(or env) updated. - Dockerfile:
base-image-embodied-<target>if needed;embodied-<target>-imagestage withinstall.shand default venv. If multiple envs: all install.sh calls chained in one RUN (for uv hardlink). - docker-build.yml: New job
build-embodied-<target>withBUILD_TARGET=embodied-<target>. - E2e: Config YAML in
tests/e2e_tests/embodied/; new job inembodied-e2e-tests.yml(install env, runrun.sh <config_name>, clean up).
When not to use it
- →Modifying existing model behavior
- →Updating infrastructure versions
Prerequisites
Limitations
- →Requires adherence to specific shell variable patterns
- →Limited to predefined supported model categories
How it compares
It synchronizes multi-layer configuration changes across three distinct CI/CD domains simultaneously.
Compared to similar skills
add-install-docker-ci-e2e side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| add-install-docker-ci-e2e (this skill) | 1 | 3mo | No flags | Advanced |
| deployment-engineer | 4 | 4mo | No flags | Advanced |
| devops-engineer | 1 | 3mo | Review | Advanced |
| devops-engineer | 0 | 3mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by RLinf
View all by RLinf →You might also like
deployment-engineer
sickn33
Expert deployment engineer specializing in modern CI/CD pipelines, GitOps workflows, and advanced deployment automation. Masters GitHub Actions, ArgoCD/Flux, progressive delivery, container security, and platform engineering. Handles zero-downtime deployments, security scanning, and developer experience optimization. Use PROACTIVELY for CI/CD design, GitOps implementation, or deployment automation.
devops-engineer
Jeffallan
Use when setting up CI/CD pipelines, containerizing applications, or managing infrastructure as code. Invoke for pipelines, Docker, Kubernetes, cloud platforms, GitOps.
devops-engineer
I-Synergy
DevOps and CI/CD specialist. Use for building pipelines, containerization, infrastructure as code, or deployment automation. User-invocable only for production deployments.
platform-engineering
villadalmine
>-
manage-gh-runners
radixark
Add, remove, list, or swap GitHub Actions self-hosted runners on a CI host that uses the env-var-driven `gh-runner` docker image (raw `docker run`, no compose). Triggers, "add gh runner", "remove gh runner", "list ci runners", or similar. Run `setup-ci-host` first if /data/miles_ci is not yet provis
add-linux-bootstrap-platform
ponylang
Load when adding a new Linux distro/version (e.g. Alpine 3.24, Ubuntu 26.04) — or both arches for an existing one — as a fully supported ponyup bootstrap-test target. Covers the bootstrap-tester Dockerfile, image build dispatch and tag discovery, CI workflow updates (tier 1 / tier 2), ponyup-init.sh