Concrete configurations for using DING with specific platforms — CI/CD runners, orchestration systems, and ML training platforms. Every recipe shows the minimal config needed to get an alert firing when a workload exits, then enumerates the auto-captured labels and any platform-specific tradeoffs.
Recipes follow a three-tier integration program:
- Tier 1 — Recipe (this directory): a docs page using the existing
dingbinary on a specific platform. Most platforms stop here. - Tier 2 — Thin integration: a separate repo (e.g.
ding-actionfor GitHub Actions). Built only when a recipe self-promotes via the escalation rubric printed at the bottom of each recipe. - Tier 3 — Operator / SDK: real code (CRD, callback library). Reserved for the few platforms where Tier 2 isn't enough.
Recipes marked Tier-2 candidate in the table below have self-evaluated as exceeding the rubric thresholds; promotion to a real Tier-2 repo happens when 2+ users confirm the friction.
| Recipe | Category | Tier | Status |
|---|---|---|---|
| GitHub Actions | CI/CD | Tier 2 (separate repo) | shipped |
| GitLab CI | CI/CD | Tier 1 | shipped |
| Jenkins | CI/CD | Tier 1 | shipped (Tier-2 candidate) |
| Buildkite | CI/CD | Tier 1 | shipped (Tier-2 candidate) |
| Kubernetes Jobs / CronJobs | Orchestration | Tier 1 | shipped (Tier-2 candidate) |
| Argo Workflows | Orchestration | Tier 1 | shipped (Tier-2 candidate) |
| MLflow | ML | Tier 1 | shipped |
| Ray Train / Tune | ML | Tier 1 | shipped (Tier-2 candidate) |
| Modal | ML | Tier 1 | shipped (Tier-2 candidate) |
The canonical recipe shape lives in _template.md. All recipes conform to it.