Dear GitHub: no YAML anchors, please

Original Article ↗ Hacker News Discussion ↗

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.