Skip to content

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

MethodBest forSetup
GitHub CodespacesPR review, zero local setupCreate a codespace from the devtools repo
VS Code devcontainerLocal development with DockerClone devtools repo, reopen in container
docker runHeadless / CIdocker 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:

Terminal window
# defaults to rw-cli-codecollection on main
task setup
# specific repo + PR
task setup REPO=runwhen-contrib/rw-cli-codecollection PR=42
# different codecollection and branch
task setup REPO=runwhen-contrib/azure-c7n-codecollection BRANCH=feat/foo

task 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 executionro --test "Check Health" runbook.robot
Terminal window
ro # run all .robot files in current dir
ro runbook.robot # run a specific file
ro --test "Check Health" # run a specific test case
ro ../other-codebundle/ # run tests in a different directory

Credentials

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 runner

ro 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.

SkillCovers
generation-rules-kubernetes.mdK8s resource types, match rules, qualifiers, templates
generation-rules-aws.mdAWS resource types, CloudQuery tables, account qualifiers
generation-rules-azure.mdAzure + Azure DevOps platforms, resource groups, subscriptions
generation-rules-gcp.mdGCP resource types, project qualifiers
sli-authoring.mdIn-repo SLIs, cron-scheduler SLIs, scoring patterns
test-infra-kubernetes.mdStatic manifests, Terraform patterns, Taskfile contract
test-infra-azure.mdAzure Terraform test infra, tf.secret, workspaceInfo
test-infra-azure-devops.mdDevOps projects, pipelines, agent pools via Terraform
test-infra-cloud.mdShared conventions across all cloud platforms
skill-template-authoring.mdGeneral Skill Template structure and conventions

Re-install after an update:

Terminal window
task install-skills

Dev 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:

Terminal window
export RW_MODE=dev
export 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.