Dear GitHub: no YAML anchors, please
33 comments
·September 22, 2025anttiharju
TheDong
Wanna DRY out your github actions yaml?
Generate it from Dhall, or cue, or python, or some real language that supports actual abstractions.
If your problem is you want to DRY out yaml, and you use more yaml features to do it, you now have more problems, not fewer.
usrme
Seconded. I've had huge success with generating workflows with CUE. Would definitely recommend it to anyone struggling with YAML.
pacoWebConsult
Can YAML go away entirely and instead allow pipelines to be defined with an actual language? What benefits does the runner-interpreted yaml-defined pipeline paradigm actually achieve? Especially with runners that can't be executed and tested locally, working with them is a nightmare.
mhh__
I'm not convinced there should be anything to define at all versus basically just some extremely broad but bare platform and a slot to stick an executable in.
datadrivenangel
Locally hard to test is the point. Lockin.
red_hare
I'm surprised by this take. I love YAML for this use case. Easy to write and read by hand, while also being easy to write and read with code in just about every language.
pacoWebConsult
Sure, easy to read, but quite difficult to /reason/ about in your head, let alone have proper language server/compiler support given the abstraction over provider events and runner state. I have never written a CI pipeline correctly without multiple iterations of pushing updates to the pipeline definition, and I don't think I'm alone on that.
TheDong
> Easy to write and read by hand, while also being easy to write and read with code in just about every language
Language implementations for yaml vary _wildly_.
What does the following parse as:
some_map:
key: value
no: cap
{'some_map': {False: 'cap', 'key': 'value'}}
The other gives me:
{'some_map': {'false': 'cap', 'key': 'value'}}
... and neither gives what a human probably intended, huh?
sauercrowd
That only matters if you're parsing the same yaml file with different parsers, which GitHub doesn't (and I doubt most people do - it's mostly used for config files)
shadowgovt
[delayed]
Pxtl
It's less about YAML itself than the MS yaml-based API for interacting with build-servers. It's just so hard to check and test and debug.
Pxtl
Yes. Most of my custom pipeline stuff is a thin wrapper around a normal-ass scripting-language because the yaml/macro stuff is so hard to check and debug.
dan_manges
We support anchors in our CI/CD syntax at RWX, but only in a specific `aliases` section. I think this is a nice compromise.
aliases:
common-env: &common-env
key1: value1
key2: value2
tasks:
- key: some-task
run: ...
env:
<<: *common-env
kpcyrd
For context:
- The complaint is Github using a non-standard, custom fork of yaml
- This makes it harder to develop linters/security tools (as those have to explicitly deal with all features available)
- The author of this blogpost is also the author of zizmor, the most well-known Github Actions security linter (also the only one I'm aware of)
baobun
YAML anchors are a welcome feature and will allow us to DRY some of our uglier workflows that currently have a lot of redundancy/duplication.
OPs main argument seems to be "I don't have a use for it and find it hard to read so it should be removed".
nirvdrum
The argument that this is a security issue isn't very well fleshed out either. As far as I can tell, it boils down to his opinion that this makes YAML harder to read and thus less secure. But, the reality is we have to copy & paste config today and that's a process I've seen fail when a change needs to be made and isn't properly carried forward to all locations. I suppose I could argue that's a security concern as well.
Half the argument against supporting YAML anchors appears to boil down some level of tool breakage. While you can rely on simplifying assumptions, you take a risk that your software breaks when that assumption is invalidated. I don't think that's a reason to stop evolving software.
I've never seen a project use any of the tools the author listed, but I have seen duplicated config. That's not to say the tools have no value, but rather I don't want to be artificially restricted to better support tools I don't use. I'll grant that the inability to merge keys isn't ideal but, I'll take what I can get.
woodruffw
(I'm the author.)
I don't think this is a fair characterization: it's not that I don't have a use for it, but that I think the uses are redundant with existing functionality while also making static and human analysis of workflows harder.
willseth
I think the main reason you see overwhelming support for anchors is that the existing Actions functionality is typically so cumbersome to implement and often makes it harder to understand a workflow. Anchor syntax is a little esoteric, but otherwise very simple and grokable.
GuinansEyebrows
is your criticism leveled at yaml anchors or github? in my anecdotal experience, yaml anchors were a huge help (and really, really not hard to grasp at a conceptual level) in maintaining uniform build processes across environments.
woodruffw
It is specifically leveled at YAML anchors in GitHub. I don't have a super strong opinion of YAML anchors in other contexts.
(This post is written from my perspective as a static analysis tool author. It's my opinion from that perspective that the benefits of anchors are not worth their costs in the specific context of GitHub Actions, for the reasons mentioned in the post.)
willseth
YAML anchors may be a sharp tool but no one is forced to use them. I have written many verbose Github workflows that would have benefited from using anchors, and I am relieved to learn I can clean those up now.
a_t48
Anchors will be exceptionally useful for a few workflows for me. We have what is essentially the same setup/teardown for three jobs within one workflow. I’d love to be able to factor that stuff out without introducing yet another yaml file to the repo, this will be a big help.
null
theamk
Author's replacement for anchors is to use global syntax, like a top-level "env:" block.
This is a terrible advice from security endpoint - given that env variables are often used for secrets data, you really _don't_ want them to set them at the top level. The secrets should be scoped as narrow as possible!
For example, if you have a few jobs, and some of them need to download some data in first step (which needs a secret), then your choices are (a) copy-paste "env" block 3 times in each step, (b) use the new YAML anchor and (c) set secret at top-level scope. It is pretty clear to me that (c) is the worst idea, security wise - this will make secret available to every step in the workflow, making it much easier for malware to exfiltrate.
javcasas
General YAML anchors as implemented by the standard: good (not great, just good).
Custom YAML anchors with custom support and surprise corner cases: bad.
raincole
It seems that any data-orient approach would inevitably evolve into a programming language given enough time.
One day we might even see for-loop in CSS...
andreareina
There are languages specifically for writing configs. Like dhall https://dhall-lang.org/
eblume
That's my thought as well. I predict we'll be seeing SDK's for generating github workflows by mid-2026. Maybe pulumi will get an extension for it. (I'm well aware that codegen yaml has been a thing for a long time, but I'm thinking about something targeting github workflows _specifically_.)
TBH it's getting a bit exhausting watching us go through this hamster wheel again and again and again.
qwerty2000
Just because it is expressed in YAML doesn't make YAML the party to blame here. I would say one of the main concerns I have with anything in GitHub Actions related to the word "merge" has to do with identifying the last commit for a merge, not merging of objects in YAML.
If you have two workflows... one to handle a PR creation/update and another to address the merge operation, it is like pulling teeth to get the final commit properly identified so you can grab any uploaded artifacts from the PR workflow.
I think YAML anchors in GitHub Actions are very welcome, for example for DRYing the push/pull_request 'paths:' filters [1].
Now only if they supported paths filter for `workflow_call` [2] event in addition to push/pull_request and my life would be a lot easier. Nontrivial repos have an unfortunate habit of building some sort of broken version of change detection themselves.
The limit of 20 unique workflow calls is quite low too but searching the docs for a source maybe they have removed it? It used to say
> You can call a maximum of 20 unique reusable workflows from a single workflow file.
but now it's max of 4 nested workflows without loops, which gives a lot of power for the more complex repos [3]. Ooh. Need to go test this.
[1] https://docs.github.com/en/actions/reference/workflows-and-a...
[2] https://docs.github.com/en/actions/reference/workflows-and-a...
[3] https://docs.github.com/en/actions/how-tos/reuse-automations...