Dear GitHub: no YAML anchors, please

Original Article ↗ Hacker News Discussion ↗

GitHub’s move to support YAML anchors in Actions workflows has reignited debate over how complex CI configuration should be. Supporters welcome anchors as a standard, widely understood way to eliminate duplication in large, repetitive workflow files, arguing they improve maintainability and reduce copy‑paste errors. Critics counter that anchors complicate static analysis, blur the boundary between “simple config” and a de facto programming language, and highlight that GitHub already implements a bespoke YAML subset, raising questions about tooling, security, and whether CI should instead be defined in real programming languages or higher-level generators.

Value of YAML anchors in CI / GitHub Actions

  • Many commenters are strongly positive on anchors, especially for DRYing repetitive bits in workflows (env blocks, paths: filters, setup/teardown steps, agent selection, etc.).
  • Experience from other systems (GitLab CI, Buildkite, RWX) is cited: anchors are described as “the real feature” that makes large pipelines maintainable, especially when combined with patterns like “dot targets” or a dedicated aliases section.
  • Several note they’ve been copying long lists or config blocks into many jobs; anchors would reduce duplication and corresponding maintenance and security mistakes.

Concerns about anchors in GitHub Actions specifically

  • The article’s author emphasizes a static-analysis perspective: common YAML parsers flatten anchors into a JSON-like tree, losing information about where reused values originated.
  • This loss of source mapping makes it harder to produce precise diagnostics with source spans (e.g., SARIF), and thus harder to analyze workflows for security issues.
  • The criticism is not of anchors in all contexts, but of adding another cross-cutting mechanism on top of an already complex, partially-templated Actions model.

YAML spec compliance vs “GitHub-flavored YAML”

  • One side argues: if GitHub says workflows are YAML, they should implement the spec (anchors, 1.2 booleans, etc.), or clearly brand it as a custom subset with its own extension.
  • Others reply that full conformance to a complex spec is not inherently good; engineering “taste” may justify supporting only a subset, especially to keep analysis simpler.
  • There’s debate over YAML 1.1 vs 1.2, merge keys, and the “Norway = false” issue, with broad agreement that real-world parsers implement fuzzy, mixed subsets anyway.

Security and design trade-offs

  • Some see anchors as improving security by avoiding out-of-sync copy-paste, especially for things like path filters.
  • Others worry that the author’s suggested alternative (hoisting env/secrets to a higher scope) is actually worse, since secrets should be scoped as narrowly as possible.
  • A recurring theme: more expressive configuration (anchors, templating) inevitably makes static reasoning harder; where to draw that line is contested.

Alternatives and broader YAML fatigue

  • Several advocate generating GitHub YAML from Dhall, CUE, Jsonnet, TypeScript, Python, etc., or using composite actions/reusable workflows instead of anchors.
  • Others push back that adding custom generators, languages, and build steps is often overkill for 200–500 line workflows and raises the contribution barrier.
  • Many commenters vent general frustration with YAML (complex spec, inconsistent parsers) and CI UX (poor validation, no reliable local runs), with some wishing CI pipelines were defined in a real programming language or at least a better-designed DSL.