DART CI/CD Troubleshooting

Load this skill when debugging CI failures or working with GitHub Actions.

When the failing claim depends on 3D structure or behavior, also load dart-verify-sim and reproduce it with a text oracle plus assessed visual evidence, or record why that renderer is unavailable in the failing environment.

Quick Commands

# Monitor PR checks
gh pr checks <PR_NUMBER>
gh pr checks <PR_NUMBER> --watch --interval 30 --fail-fast

# View run details
gh run list --branch <BRANCH> -e pull_request -L 20
gh run watch <RUN_ID> --interval 30
gh run view <RUN_ID> --json status,conclusion,url

# Debug failures
gh run view <RUN_ID> --job <JOB_ID> --log-failed
gh run view <RUN_ID> --json jobs --jq '.jobs[] | {name, databaseId}'

# Rerun failed jobs only after explicit maintainer/user approval
gh run rerun <RUN_ID> --failed
gh run rerun <RUN_ID> --job <DATABASE_ID>

Full Documentation

For complete CI/CD guide: docs/onboarding/ci-cd.md

Common Failure Modes

Workflow Architecture

The CI gates that a PR check name maps to (full 18-workflow table with triggers: docs/onboarding/ci-cd.md § "Workflow Architecture"):

CUDA Runner Policy

The project has a trusted ubuntu-latest-gpu runner for same-repository CUDA runtime validation, but it must never run untrusted fork-PR code. Consequences:

• Same-repository PRs, protected branch pushes, and manual dispatches use the GPU runner and run pixi run --locked -e cuda test-cuda.
• Fork PRs use a GitHub-hosted fallback and compile CUDA targets without running GPU-only steps.
• Local CUDA validation is pixi run -e cuda test-all on Linux hosts with a visible NVIDIA CUDA runtime; local Pixi config auto-detects visible GPU compute capabilities for DART_CUDA_ARCHITECTURES.
• pixi run check-phase5-cuda-workflow enforces the trusted-event GPU guard and fork-PR hosted fallback in ci_cuda.yml.

Fast Iteration Loop

1. Identify failing step from job logs
2. Reproduce locally with same build toggles
3. Fix the smallest failing test
4. Push only after explicit maintainer/user approval, then monitor: gh run watch <RUN_ID>

Caching And Timing

Use the cache policy, current timing guidance, and investigation steps in docs/onboarding/ci-cd.md. Treat observed job duration and cache diagnostics from the affected run as the current evidence; do not copy mutable timing or hit-rate estimates into this skill.