README.md

metadata

title: Cloud-Native DevOps Debug Environment
emoji: 🔧
colorFrom: blue
colorTo: green
sdk: docker
app_port: 7860
pinned: false

Cloud-Native DevOps Debug Environment

An OpenEnv-compatible environment where AI agents learn to debug broken GitHub Actions workflows, Dockerfiles, and Kubernetes manifests. Built for the OpenEnv Hackathon by Scaler School of Technology (partners: Meta, HuggingFace, PyTorch).

Why Cloud-Native Debugging?

Every developer who ships code hits deployment pipeline failures. A misconfigured Dockerfile, a broken GitHub Actions workflow, a missing secret, a Kubernetes selector mismatch — these are the bugs that waste hours of developer time every week. They're hard to debug because:

• Error messages are cryptic ("unable to prepare context: unable to evaluate symlinks")
• The feedback loop is slow (push, wait for CI, read logs, fix, repeat)
• Multiple config files interact in non-obvious ways (Dockerfile + workflow + secrets + K8s manifests)
• Kubernetes errors require cross-resource reasoning (Deployment labels must match Service selectors)

This environment teaches AI agents to do what senior DevOps engineers do: read the error, trace it to the root cause across multiple files, and fix it.

---

How It Works: The Complete Flow

┌──────────────────────────────────────────────────────────────┐
│  1. RESET                                                     │
│     Agent receives:                                           │
│     - Broken config files (Dockerfile / workflow / K8s YAML)  │
│     - Error message from the failed build/deploy              │
│     - Available secrets list                                  │
│     - Number of issues to find                                │
├──────────────────────────────────────────────────────────────┤
│  2. OBSERVE → THINK → ACT  (repeat up to 10 steps)           │
│     Agent reads the error, analyzes the files, then:          │
│     - edit_file: replace broken content with fixed content    │
│     - replace_line: fix a specific line number                │
│     - add_line / add_block: insert missing content            │
│     - delete_line / delete_block: remove bad content          │
│     - request_hint: get a clue (-4% score penalty)            │
│     - submit: "I'm done fixing"                               │
│                                                               │
│     After each action, agent gets:                            │
│     - Updated file contents                                   │
│     - Reward signal (+0.3 per fix, -0.02 for failed edits)   │
│     - How many issues are now fixed                           │
├──────────────────────────────────────────────────────────────┤
│  3. GRADE                                                     │
│     Deterministic scoring based on:                           │
│     - What fraction of issues were fixed                      │
│     - Whether ALL issues were fixed (bonus)                   │
│     - How many steps it took (efficiency)                     │
│     - How many hints were used (penalty)                      │
│     Score range: (0, 1) exclusive — never exactly 0 or 1     │
└──────────────────────────────────────────────────────────────┘

---

The 10 Tasks (50 Scenarios)

Evaluation runs all 50 scenarios deterministically across all 10 tasks for reproducible scoring.

Task 1: Dockerfile Syntax Errors — Easy

Simple typos and instruction errors that break docker build.

#	Scenario	What's Broken	Real-World Context
1	typo_filename	COPY requirments.txt . — misspelled filename	Most common Docker build error on Stack Overflow
2	invalid_base_image	FROM python:3.9-slimm — extra 'm' in tag	Happens when copy-pasting image tags
3	invalid_run_syntax	RUN pip install ... \n && python setup.py — broken line continuation	Formatting multi-line RUN commands is tricky
4	copy_missing_source	COPY dist/ but build output is in build/	Source directory doesn't exist in build context
5	missing_from_instruction	No FROM instruction at all	Dockerfile must start with FROM

Task 2: Dockerfile Runtime Errors — Medium

The Dockerfile builds successfully, but the container crashes at runtime.

#	Scenario	What's Broken	Real-World Context
1	missing_workdir	No WORKDIR — files scatter to /	Container runs but npm start can't find package.json
2	cmd_entrypoint_conflict	Both ENTRYPOINT and CMD defined as full commands	Process starts incorrectly
3	entrypoint_not_executable	Shell script lacks execute permission	chmod +x missing — "permission denied"
4	missing_required_env	App needs DATABASE_URL but it's not set	Container crashes: "DATABASE_URL is not defined"
5	non_root_privileged_port	Non-root user tries to bind port 80	Security best practice conflicts with port < 1024

Task 3: Workflow Syntax & Structure — Easy

GitHub Actions YAML has structural problems that GitHub rejects before any job runs.

#	Scenario	What's Broken	Real-World Context
1	checkout_after_build	docker build before actions/checkout	No source code — "Dockerfile not found"
2	missing_runs_on	Job has no runs-on field	Every job needs a runner
3	invalid_trigger_syntax	branches: main instead of branches: [main]	Must be a YAML list
4	missing_step_uses_or_run	Step has a name but no uses: or run:	Invalid step
5	missing_on_trigger	No on: block at all	Workflow never triggers

Task 4: Workflow Secrets & Permissions — Medium

Secrets exist but aren't wired correctly to the workflow steps.

#	Scenario	What's Broken	Real-World Context
1	missing_env_secrets	$DOCKER_PASSWORD without env: mapping	Secrets must be passed via env: block
2	wrong_secret_syntax	${ secrets.TOKEN } instead of ${{ secrets.TOKEN }}	Single vs double braces
3	missing_token_permissions	Pushing to GHCR without permissions: packages: write	GITHUB_TOKEN is read-only by default
4	secret_not_in_env	$SLACK_WEBHOOK_URL not in env:	Very common mistake
5	ghcr_wrong_credentials	Using DOCKER_PASSWORD for GHCR login	GHCR uses GITHUB_TOKEN

Task 5: CI + Docker Integration — Medium

The workflow AND the Dockerfile interact. Fixing one file alone isn't enough.

#	Scenario	What's Broken	Real-World Context
1	missing_buildx_for_platforms	Multi-platform build without setup-buildx-action	Need BuildKit for cross-compile
2	missing_load_true	build-push-action without load: true — next step can't find image	Buildx doesn't load into local daemon by default
3	wrong_build_context	Context is ./backend but Dockerfile path is ./Dockerfile	Path mismatch
4	cache_without_mode_max	GHA cache export missing mode=max	Cache doesn't persist
5	push_without_login	docker push without docker login first	"denied: requested access"

Task 6: Multi-Stage Pipeline & Matrix — Hard

Complex pipelines with multiple interacting bugs. Agent must find 2-3 issues across files.

#	Scenario	What's Broken	Real-World Context
1	artifact_path_mismatch	COPY --from=builder /app/dist but React outputs to /app/build	CRA uses build/, Vite uses dist/
2	matrix_platform_arg	$BUILDPLATFORM without ARG BUILDPLATFORM	Multi-arch needs platform ARGs
3	cross_job_artifact	Test job downloads artifact but missing needs: build	Jobs run in parallel by default
4	multiple_issues	Dockerfile typo + workflow secrets not wired (2 bugs)	Problems compound across files
5	matrix_version_failure	Matrix includes Node 14 but code needs >= 16 + missing needs:	2 bugs to find

Task 7: Kubernetes Pod Failures — Medium

Pod crashes and scheduling failures in Kubernetes deployments.

#	Scenario	What's Broken	Real-World Context
1	oom_killed	Memory limit 64Mi too low — CrashLoopBackOff/OOMKilled	Most common K8s production issue
2	image_pull_backoff	Image tag typo nginx:latset → ImagePullBackOff	Copy-paste tag errors
3	wrong_command	command: ["python", "workers.py"] but file is worker.py	File name mismatch
4	missing_configmap	envFrom: configMapRef: app-config but ConfigMap doesn't exist	CreateContainerConfigError
5	liveness_probe_failing	Liveness probe port 3000 but app listens on 8080	Probe misconfiguration causes restarts

Task 8: Kubernetes Service & Ingress Issues — Hard

Networking issues where pods run fine but traffic doesn't reach them. Error messages are intentionally vague — the agent must diagnose from kubectl output.

#	Scenario	What's Broken	Real-World Context
1	selector_mismatch	Service selector app: api but pod label is app: api-server	No endpoints — most common K8s networking bug
2	port_mismatch	Service targetPort 8080 but container listens on 3000	Connection refused
3	ingress_wrong_service	Ingress references api-svc but service name is api-service	Ingress 404
4	network_policy_blocking	NetworkPolicy with empty ingress rules blocks all traffic	Database unreachable
5	missing_ingress_class	No ingressClassName: nginx specified	Ingress controller doesn't pick it up

Task 9: CI/CD Build & Push Pipeline — Hard

GHA-to-Docker-to-Registry pipeline failures spanning multiple files.

#	Scenario	What's Broken	Real-World Context
1	registry_mismatch	Build tags ghcr.io/... but push targets docker.io/...	Registry URL mismatch between steps
2	image_tag_mismatch	Build uses github.ref_name but push uses github.sha	"image not found locally"
3	inconsistent_tagging	docker tag myuser/api:latest but image was built as myuser/api:${{ github.sha }}	Tag source doesn't exist
4	build_arg_not_passed	Dockerfile ARG APP_VERSION but no --build-arg in workflow	Version file is empty
5	dockerfile_path_in_subdirectory	Workflow points to ./Dockerfile but it's at ./services/api/Dockerfile	Monorepo path mismatch

Task 10: Full Stack Deployment Pipeline — Expert

Multi-error scenarios spanning the entire stack: GHA + Dockerfile + K8s manifests. 2-4 bugs per scenario requiring cross-file reasoning. Error messages are intentionally vague — the agent must trace root causes from symptoms.

#	Scenario	What's Broken	Real-World Context
1	full_pipeline_ghcr_and_selector	GHCR token not mapped + K8s Service selector mismatch	2 bugs across workflow + K8s
2	full_pipeline_three_bugs	Missing checkout + no WORKDIR + wrong container/service port	4 bugs across 4 files
3	full_pipeline_ghcr_dockerfile_k8s	Wrong GHCR secret + base image typo + OOM memory limit	3 bugs across all layers
4	full_pipeline_permissions_image_ingress	Missing packages:write + hardcoded image placeholder + no ingressClassName	3 bugs
5	full_pipeline_secrets_build_probe	Docker secrets not wired + wrong build output dir + probe port mismatch	4 bugs across all layers

---

Fix Validation: Simulator-Based

Fixes are validated using structural simulators, not string matching. This means:

• Alternative valid fixes are accepted. Setting memory to 512Mi instead of 256Mi both resolve the OOM — the simulator accepts either.
• Three independent simulators run after every edit:
  • DockerSimulator: validates Dockerfile syntax (FROM, COPY, EXPOSE, RUN) and runtime behavior (WORKDIR, CMD/ENTRYPOINT, permissions, ENV)
  • WorkflowSimulator: parses YAML, checks triggers, runs-on, step ordering, secrets wiring, permissions, buildx requirements, registry consistency
  • KubernetesSimulator: validates manifests, cross-resource dependencies (Service selector ↔ Deployment labels), pod status simulation (OOM, ImagePullBackOff), service endpoint reachability
• 7 granular checks are tracked: docker_build, docker_run, workflow_parse, workflow_exec, k8s_valid, k8s_pod_running, k8s_service_active
• Progress = how many checks flip from fail → pass compared to the initial broken state

---

Available Actions

Each step, the agent chooses exactly one action:

Action	What It Does	When to Use
edit_file	Replace old_content with new_content in a file	Most common — fix a broken line or block
replace_line	Replace content at a specific line number	When you know exactly which line is wrong
add_line	Insert a new line into a file	Adding missing instructions (e.g., missing WORKDIR)
delete_line	Remove a specific line	Removing a bad instruction
add_block	Insert a multi-line block	Adding entire sections (e.g., env: block with secrets)
delete_block	Remove a multi-line block	Removing incorrect sections
request_hint	Get a clue about what's wrong	Costs -4% on final score — use sparingly
submit	Declare "I'm done" — triggers final evaluation	When all fixes are applied

Important: edit_file requires old_content to match exactly (including whitespace). If it doesn't match, the edit fails and the agent gets a -0.02 reward penalty.

---

Grading System

Scoring is deterministic (same actions always produce the same score), difficulty-aware (harder tasks are graded more generously), and scores are strictly in (0, 1) exclusive — never exactly 0 or 1.

The Formula

FINAL SCORE = Base + Partial Fixes + Complete Bonus + Difficulty Bonus + Efficiency - Hint Penalty - Failed Edit Penalty

Clamped to (0.01, 0.99).

Component Breakdown

Component	Weight	Description
Base score	5%	Participation credit (guarantees score > 0)
Partial fixes	35%	Proportional to issues_fixed / issues_total
Complete bonus	25%	All issues fixed
Difficulty bonus	0-3%	Extra reward for fully solving hard/expert tasks
Efficiency	25%	Decays with extra steps — slower decay for harder tasks
Hint penalty	-3% to -4% each	Per request_hint action (cheaper for hard/expert)
Failed edit penalty	-2% each	Per edit with no valid file path

Difficulty Modifiers

Difficulty	Max Score	Efficiency Decay	Hint Cost
Easy	0.90	0.03/step (strict)	4% each
Medium	0.90	0.027/step	4% each
Hard/Expert	0.93	0.021/step (forgiving)	3% each

---

Evaluation

The evaluation pipeline runs all 50 scenarios across all 10 tasks deterministically:

# Runs all 10 tasks × 5 scenarios = 50 episodes
results = run_baseline_episodes()  # num_episodes=None runs all

# Per-episode scores in (0, 1)
# Aggregate = mean of all 50 scores
aggregate = sum(r.score for r in results) / len(results)

This ensures:

• Reproducibility: same agent produces same score every time
• Complete coverage: every error pattern is tested
• Fair comparison: all agents face the same 50 scenarios

---

API Endpoints

Endpoint	Method	Description
/	GET	Root page
/health	GET	Health check — returns {"status": "healthy"}
/metadata	GET	Environment name, description, version, tags
/schema	GET	Action, observation, and state JSON schemas
/reset	POST	Start a new episode (optional: task_id, scenario_id, seed)
/step	POST	Take an action and receive observation + reward
/state	GET	Get current observation without taking an action
/info	GET	Task list with metadata
/tasks	GET	List all tasks with difficulty levels
/grader	POST	Grade a trajectory (list of step dicts)
/baseline	POST	Run baseline across all scenarios (optional: task_id, num_episodes)
/mcp	POST	JSON-RPC 2.0 MCP endpoint (initialize, tools/list)

Example: Full Episode via API

# 1. Start an episode
curl -X POST http://localhost:7860/reset \
  -H "Content-Type: application/json" \
  -d '{"task_id": "k8s_pod_failures", "scenario_id": "oom_killed"}'

# 2. Fix the memory limit (any reasonable value works — simulator validates structurally)
curl -X POST http://localhost:7860/step \
  -H "Content-Type: application/json" \
  -d '{
    "action": {
      "action_type": "edit_file",
      "edits": [{
        "file_path": "k8s/deployment.yaml",
        "old_content": "memory: \"64Mi\"",
        "new_content": "memory: \"512Mi\""
      }]
    }
  }'

# Response: reward=0.3, issues_fixed=1/1, done=true

---

Quick Start

Local Development

pip install -r requirements.txt
python -m uvicorn server.app:app --host 0.0.0.0 --port 7860

Run Tests

pytest tests/ -v

Docker

docker build -t cloud-native-devops-env .
docker run -p 7860:7860 cloud-native-devops-env

Baseline Inference (with LLM)

export API_BASE_URL=https://router.huggingface.co/v1
export MODEL_NAME=meta-llama/Llama-3.1-70B-Instruct
export HF_TOKEN=your_token_here
python inference.py

---

Project Structure

cloud-native-devops-env/
├── openenv.yaml              # OpenEnv environment specification
├── inference.py              # LLM baseline (OpenAI client + HF router)
├── baseline_runner.py        # Heuristic baseline — runs all 50 scenarios
├── Dockerfile                # Production container
├── requirements.txt          # Python dependencies
│
├── server/
│   ├── app.py                # FastAPI with 12 endpoints
│   ├── models.py             # Pydantic models (type-safe API)
│   ├── environment.py        # Core environment loop (reset/step/state)
│   ├── tasks/
│   │   ├── base.py           # BaseTask with scenario loading
│   │   ├── task_registry.py  # Maps task_id → task class (10 tasks)
│   │   ├── task_1_build_errors.py        # 5 Dockerfile syntax scenarios
│   │   ├── task_2_docker_runtime.py      # 5 Dockerfile runtime scenarios
│   │   ├── task_3_workflow_syntax.py     # 5 workflow structure scenarios
│   │   ├── task_4_workflow_secrets_permissions.py  # 5 secrets scenarios
│   │   ├── task_5_ci_docker_integration.py        # 5 integration scenarios
│   │   ├── task_6_multi_stage_matrix.py           # 5 multi-issue scenarios
│   │   ├── k8s_pod.py                   # 5 Kubernetes pod failure scenarios
│   │   ├── k8s_networking.py            # 5 K8s networking scenarios
│   │   ├── pipeline_build_deploy.py     # 5 GHA→Docker→Registry scenarios
│   │   └── pipeline_full.py             # 5 full-stack multi-error scenarios
│   ├── graders/
│   │   └── __init__.py       # Deterministic trajectory grader
│   └── simulators/
│       ├── docker_simulator.py   # Dockerfile build + runtime validation
│       ├── workflow_simulator.py # GHA workflow parse + execution validation
│       └── k8s_simulator.py     # K8s manifest + cross-resource validation
│
└── tests/
    ├── test_endpoints.py     # API endpoint tests
    ├── test_determinism.py   # Grader determinism + score range tests
    ├── test_baseline.py      # Heuristic baseline tests
    ├── test_environment_flow.py  # Episode flow tests
    └── test_simulators.py    # Simulator unit tests

Design Decisions

1. Full cloud-native stack: Docker + GitHub Actions + Kubernetes — the three pillars of modern deployment pipelines.
2. Simulator-based validation: Structural rule-based simulators validate fixes instead of string matching. Alternative valid fixes are accepted (e.g., 512Mi and 256Mi both fix an OOM). Deterministic, fast, no security concerns.
3. Dense rewards: Partial credit at every step (+0.3 per fix, -0.02 per failed edit) rather than sparse pass/fail.
4. Difficulty progression: Easy tasks are single-file, single-issue. Expert tasks are multi-file, multi-issue with interacting bugs across all three layers.
5. Vague error messages in harder tasks: Easy tasks have explicit error messages. Hard/Expert tasks have realistic, vague messages that require the agent to actually diagnose the issue from context.
6. Deterministic evaluation: All 50 scenarios run every time for reproducible, comparable scores in (0, 1) exclusive.
7. 50 scenarios from real bugs: Every scenario is based on actual developer mistakes documented on Stack Overflow, GitHub Issues, and official documentation.

License

MIT