Skip to content

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

226 Commits

Folders and files

Repository files navigation

RLE samples

RLE has two implementation types: Gym and Harness. Every environment carries a host-agnostic rle.toml manifest declaring its immutable identity and callable interface:

[rle]
name = "code_rl"
version = "1.0.0"

[harness]
type = "gym"

The [harness] table (type, endpoint, protocol) matches the RLE control plane harness object. The manifest intentionally does not contain Foundry project endpoints, registry locations, service IDs, or credentials.

RLE SDK installation

All four RLE container samples install azure-ai-projects[rle] wheels from the public SDK manifest, hosted by Azure/azure-sdk-for-python#49488. The SDK is installed inside the container during azd ai rle publish; no host SDK installation, SDK source-fork access, or GitHub credentials are required. Each sample includes install_rle_sdk.py in its own Docker build context. The Dockerfile copies the installer locally; it is not downloaded during builds. The installer selects the requested version and verifies its SHA-256 before running pip. Docker fetches the registry JSON over HTTPS, then the installer downloads only the selected wheel from its registry URL. Local development uses the same download flow. Approved version paths must not be overwritten, and a checksum mismatch always fails installation. Keep the four installer copies identical when updating them. Each sample retains its own build context and includes its installer when scaffolded by the CLI.

Each sample's Dockerfile sets ENV AZURE_AI_PROJECTS_VERSION=latest before SDK installation. To pin a version, edit that line in your local Dockerfile to an exact version listed in the manifest. A missing version fails; it never falls back. No SDK setting is needed on the azd CLI side. The Dockerfiles use HTTP ADD for the public registry JSON. When its content changes, Docker invalidates the SDK installation layer. GitHub's CDN can briefly serve an older registry; this delay is accepted. No Git fetch is needed.

The default Dockerfile setting is:

ENV AZURE_AI_PROJECTS_VERSION=latest

To pin the SDK version, change that line locally before rebuilding:

ENV AZURE_AI_PROJECTS_VERSION=2.7.0b1

For local server development outside Docker, run from the folder containing the sample's Dockerfile:

python install_rle_sdk.py --requirements requirements.txt

The local installer also accepts --version <version> for a version listed in the manifest. Docker builds use the environment value defined in the Dockerfile. Runtime container environment variables cannot change the SDK baked into an image. tools/test_rle_sdk_distribution.py checks that all sample installers match, along with version selection, checksum verification, and pip installation.

.agents/skills/ and .claude/skills/ — the authoring skills

The skills carry the RLE authoring contract: the server surface, the action vocabulary behind GET /schema, the manifest fields, grading and step budget, and the failure modes worth recognizing. A coding agent working in a project that has them can author or extend an environment without being told the contract first.

They ship twice because no single directory reaches every agent:

Agent Reads
Claude Code .claude/skills/ only
OpenAI Codex .agents/skills/
GitHub Copilot .github/skills/, .claude/skills/, .agents/skills/

The two trees must stay byte-identical. .agents/skills/ is the source of truth and .github/workflows/skills-parity.yml fails the build if they diverge, so after editing a skill mirror it across:

rm -rf .claude/skills && cp -R .agents/skills .claude/skills

azd ai rle init copies both trees into a new environment, and azd ai rle skill install refreshes them in place from this repository.

examples/gym/openenv/ — Gym/OpenEnv samples

examples/gym/openenv/ holds Gym/OpenEnv samples, where the caller drives the environment through reset/step. These are copied directly by azd ai rle init <sample-name>.

Both Gym samples use the SDK RLEnvironment MCP contract:

  • code_rl registers the typed check_solution tool and grades the final fenced Python submission.
  • math_rl registers the typed check_equivalence helper and grades the final boxed answer.

Both run under RLE's MCP environment protocol (the only one), and carry reset, MCP tool calls, and terminal GradeAction grading over one persistent OpenEnv session.

examples/gym/openenv/catalog.toml controls which sample directories azd ai rle init offers. A new sample directory is visible automatically; add an entry with visible = false to stage a sample before announcing it.

examples/harness/ — byoh harness samples (responses, rle-invocation)

examples/harness/ holds worked reference examples for the byoh type, where RLE wraps a production agent that owns its own loop: examples/harness/hosted-agent/ for agents running as a Foundry hosted agent (protocol = "responses"), and examples/harness/byoh/ for bring-your-own harnesses deployed anywhere at an https endpoint (protocol = "rle-invocation"). Each directory holds one directory per sample — today data_code_agent under both — and each sample includes the agent/harness code and the paired RLE code (task setup, mock tools, grader), plus a README covering deploy → wire → publish. Because the agent side is always specific to your own harness, azd ai rle init --type byoh scaffolds only the RLE side for you — these folders show how to build and wire the other half.

Each directory has its own catalog.toml, with the same visibility rules as the gym one. Pick a sample with azd ai rle init --sample <name>, or let the CLI prompt — it always does, even when only one sample is visible.

When a sample is initialized through azd ai rle init <folder-name>, the CLI updates rle.name to the target folder name. Before publishing another version, update rle.version to the direct next major, minor, or patch release.

code_rl compact dataset maintenance

examples/gym/openenv/code_rl ships its 900-training-task and 100-validation-task snapshot under data/, so normal Docker builds and runtime instances do not download Hugging Face data. The snapshot generator is intentionally outside the sample at tools/generate_code_rl_compact_dataset.py; it is not copied by azd ai rle init.

Maintainers can intentionally refresh the revision-pinned snapshot and its checksums from the repository root:

python tools/generate_code_rl_compact_dataset.py

The generator calls the Hugging Face datasets server, preserves no more than three complete tests and 12 KiB of test input/output per task, and updates examples/gym/openenv/code_rl/data/source.json with the selected source and file hashes.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages