dco_001 · Deployment Orchestration: create → verify config → teardown

Status: ✓ Passing · Last run: 2026-06-11T02:35:27 · Pipeline: deployment_orchestration · History: 1/10 runs passed (10%)

What was tested

Proves the spec for "deployment provisioning works." Given a real DeploymentSpec, calling deploy_to_cloud(spec, dry_run=False) must create a Cloud Scheduler entry with:

Then teardown_cloud_scheduler must delete the entry; a subsequent get_job must raise NotFound. This is the contract. The current implementation uses google-cloud-scheduler; a future implementation could use Cloud Run Jobs + Pub/Sub triggers or any other approach. It has to satisfy the same dco_001.

What we planted in the data

What the system did

What we checked — all assertions passed

Status Assertion Detail
orchestration_provisioner_succeeded provisioner returned cleanly; scheduler_job=projects/careful-acumen-389814/locations/us-central1/jobs/deploy-refresh-validation_dco_001_d…
orchestration_scheduler_config_correct scheduler entry config matches spec: schedule='0 5 * * *', tz='America/Chicago', uri=https://validation-test.example.com/worker/deploy-re…
orchestration_teardown_clean teardown deleted the entry; get_job after teardown returned NotFound

How this could have gone wrong

(no assertion descriptions provided)

Why this case matters

Without this case, "did the real provisioner work?" requires manual gcloud scheduler jobs describe. With it, the validation page is the gate — flipping dry_run=false in the FE is defended by a green test. Any future refactor of deploy_to_cloud has to keep dco_001 passing, regardless of how it implements the provisioning. Cost per run: ~$0. Cloud Scheduler's first 3 jobs are free; this test uses 1 and immediately deletes it. No LLM calls. ~10s wall-clock.

Reproducing

# from auto_insight_api/
python -m validation.v2 run dco_001 --pipeline deployment_orchestration -v

← back to validation report