Development Environment
The codecollection-devtools container is the standard development environment for authoring and testing Skill Templates (CodeBundles). One image works with any codecollection — set an env var and start developing.
Three ways to run
| Method | Best for | Setup |
|---|---|---|
| GitHub Codespaces | PR review, zero local setup | Create a codespace from the devtools repo |
| VS Code devcontainer | Local development with Docker | Clone devtools repo, reopen in container |
docker run | Headless / CI | docker run -it ghcr.io/runwhen-contrib/codecollection-devtools:latest |
All three pull the pre-built image from GHCR — no local Docker build required.
Bootstrapping a codecollection
Inside the container, run:
# defaults to rw-cli-codecollection on maintask setup
# specific repo + PRtask setup REPO=runwhen-contrib/rw-cli-codecollection PR=42
# different codecollection and branchtask setup REPO=runwhen-contrib/azure-c7n-codecollection BRANCH=feat/footask setup clones the repo, installs Python deps, installs authoring
skills as Cursor rules, and checks out the PR branch if specified.
The ro runner
ro is a thin wrapper around robot that provides:
- Isolated working directories — each run gets its own temp dir with
copied cloud CLI configs (
.azure,.gcloud,.kube) - Log output — HTML reports written to
/robot_logs, served at localhost:3000 - Selective test execution —
ro --test "Check Health" runbook.robot
ro # run all .robot files in current dirro runbook.robot # run a specific filero --test "Check Health" # run a specific test casero ../other-codebundle/ # run tests in a different directoryCredentials
Mount or copy credentials into the auth/ directory:
/home/runwhen/├── auth/│ ├── .kube/config # kubectl│ ├── .azure/ # Azure CLI│ └── .gcloud/ # Google Cloud SDK├── codecollection/│ ├── codebundles/ # your Skill Templates│ └── libraries/ # shared keyword libraries└── ro # test runnerro copies these configs into an isolated temp directory per run, so parallel
executions don’t interfere with each other.
Authoring skills
The skills/ directory in the devtools repo contains platform-specific
authoring guidance that is automatically installed as
Cursor rules during task setup.
These give AI assistants (and human authors) context about generation rules,
SLI patterns, and test infrastructure conventions.
| Skill | Covers |
|---|---|
generation-rules-kubernetes.md | K8s resource types, match rules, qualifiers, templates |
generation-rules-aws.md | AWS resource types, CloudQuery tables, account qualifiers |
generation-rules-azure.md | Azure + Azure DevOps platforms, resource groups, subscriptions |
generation-rules-gcp.md | GCP resource types, project qualifiers |
sli-authoring.md | In-repo SLIs, cron-scheduler SLIs, scoring patterns |
test-infra-kubernetes.md | Static manifests, Terraform patterns, Taskfile contract |
test-infra-azure.md | Azure Terraform test infra, tf.secret, workspaceInfo |
test-infra-azure-devops.md | DevOps projects, pipelines, agent pools via Terraform |
test-infra-cloud.md | Shared conventions across all cloud platforms |
skill-template-authoring.md | General Skill Template structure and conventions |
Re-install after an update:
task install-skillsDev mode (RW_MODE=dev)
The devtools container sets RW_MODE=dev, which activates
rw-core-keywords
dev mode. In dev mode:
- Secrets are read from environment variables or local files (not Vault)
- Metrics are logged to console (not pushed to OpenTelemetry)
- Issues are logged to console (not written to
issues.jsonl) - Reports are logged to console (not written to
report.jsonl)
Use RW_SECRET_REMAP to map variable names to different env var keys, and
RW_FROM_FILE to read secret values from local files:
export RW_MODE=devexport RW_FROM_FILE='{"kubeconfig":"/home/user/auth/kubeconfig"}'export RW_SECRET_REMAP='{"my_token":"MY_LOCAL_TOKEN_VAR"}'See the RW.Core Keyword Reference for the full dev-mode API, and the Runtime Stack section for how dev mode differs from production.