yossarian (1.3.6.1.4.1.55738)Dear GitHub: no YAML anchors, please
https://blog.yossarian.net/2025/09/22/dear-github-no-yaml-anchors
"Musty Bits" McGee@yossarian don't even need to read it - my dumb ass tried this shit a few years back with gitlab and it is HORRIBLE.
YAML has a composition problem and tbqh ime if you find yourself reaching for anchors you've passed the point where YAML is expressive enough
@yossarian oh this is damning
Roger Lipscombe@arichtman @yossarian not gh actions, but the last time I tried to use anchors, I gave up and used a templating step to generate the final yaml.
@rogerlipscombe @yossarian agree. Normally I've stayed the heck away from dynamically defining pipelines since it becomes quite opaque what's going to run and why. I'm considering using a build system though for it lately cause it seems a reasonable fit what with a DAG of reproducible, cached outputs
medium rare bird@yossarian interesting, are eagerly "copying" parsers like the ones mentioned here susceptible to some variant of billion laughs attack?
Eemeli Aro@yossarian @migratory Huh, thanks to this pointer I filed https://github.com/dubniczky/Yaml-Bomb/pull/1 to fix its test for the JS `yaml` library, as it can deal fine with a billion laugh attack like this but was just bailing out early due to detecting the bomb.
Joshua Cannon@yossarian "This, to me, suggests that the current Actions team lacks a strong set of opinions about how GitHub Actions should be used, leading to a 'kitchen sink' approach that serves all users equally poorly."
I fear the same truth as well. Or an even darker one: there is no real/tangible "Actions" team anymore.
JA@thejcannon @yossarian And the documentation for Actions is the worst, just behind Microsoft's docs. I think everyone relies on zizmor audit docs and Adnan's blogposts.
@yossarian > Furthermore, this is the reality for every YAML parser in wide use: all widespread YAML parsers choose (reasonably) to copy anchored values into each location where they’re referenced, meaning that the analyzing tool cannot “see” the original element for source location purposes.
This is not universally true. In JavaScript:
import { isAlias, parseDocument } from 'yaml'
const src = `jobs:
job1:
env: &env_vars
NODE_ENV: production
job2:
env: *env_vars`
const doc = parseDocument(src)
const alias = doc.getIn(['jobs', 'job2', 'env'])
// Alias { source: 'env_vars', range: [ 77, 86, 86 ] }
isAlias(alias) // true
src.substring(77, 86) === '*env_vars'
const envNode = doc.getIn(['jobs', 'job1', 'env'])
alias.resolve(doc) === envNode // true
See docs here: https://eemeli.org/yaml/#alias-nodes