Dear GitHub: no YAML anchors, please • Hacker News Board

Re: Dear GitHub: no YAML anchors, please

#31

Post by GuinansEyebrows » Mon, Sep 22, 2025, 3:17 PM UTC

woodruffw wrote: post #4

baobun wrote: post #2

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".

(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.

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.

Re: Dear GitHub: no YAML anchors, please

#32

Post by kpcyrd » Mon, Sep 22, 2025, 3:18 PM UTC

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)

Re: Dear GitHub: no YAML anchors, please

#33

Post by woodruffw » Mon, Sep 22, 2025, 3:19 PM UTC

GuinansEyebrows wrote: post #31

woodruffw wrote: post #4

Earlier quoted context omitted.

(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.

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.

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.)

Re: Dear GitHub: no YAML anchors, please

#34

Post by usrme » Mon, Sep 22, 2025, 3:19 PM UTC

TheDong wrote: post #14

anttiharju wrote: post #7

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 qu…

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.

Seconded. I've had huge success with generating workflows with CUE. Would definitely recommend it to anyone struggling with YAML.

Re: Dear GitHub: no YAML anchors, please

#35

Post by techlatest_net » Mon, Sep 22, 2025, 3:19 PM UTC

[dead]

Re: Dear GitHub: no YAML anchors, please

#36

Post by sevensor » Mon, Sep 22, 2025, 3:20 PM UTC

sauercrowd wrote: post #29

TheDong wrote: post #25

Earlier quoted context omitted.

> 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 If I google "yaml online" and paste it in, one gives me: {'some_map': {False: 'cap', 'key': 'value'}} The other gives me: {'some_map': {'false': 'cap', 'key': 'value'}} ... and neither gives what…

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)

“The meaning of YAML is implementation-defined” is a big reason I stay far away whenever I can.

Re: Dear GitHub: no YAML anchors, please

#37

Post by jerf » Mon, Sep 22, 2025, 3:22 PM UTC

raincole wrote: post #6

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...

I have a theory that in such cases one might as well just give up and write a Turing-complete language in the first place, as the sort of TC-complete languages we get with this sort of "slowly but surely backed against the wall" situations are way worse than just starting from scratch.

I hypothesize a TC-complete language for something like CSS that included deep tracking under the hood for where values are coming from and where they are going would be very useful, i.e., you would have the ability to point at a particular part of the final output and the language runtime could give you a complete accounting of where it came from and what went into making the decisions, could end up giving us the auditability that we really want from the "declarative" languages while giving us the full power of the programming langauges we clearly want. However I don't have the time to try to manifest such a thing myself, and I don't know of any existing language that does what I'm thinking of. Some of the more powerful languages could theoretically do it as a library. It's not entirely unlike the auditing monad I mention towards the end of https://www.jerf.org/iri/post/2958/ . It's not something I'd expect a general-purpose language to do by default since it would have bad general-purpose performance, but I think for specialized cases of a TC-complete configuration langauge it could have value, and one could always run it as an debugging option and have an optimized code path that didn't track the sources of everything.

Re: Dear GitHub: no YAML anchors, please

#38

Post by jbjbjbjb » Mon, Sep 22, 2025, 3:23 PM UTC

pacoWebConsult wrote: post #12

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.

I couldn’t agree more. I think we should just write our pipelines in languages our teams are familiar with and prioritise being able to run them locally.

Re: Dear GitHub: no YAML anchors, please

#39

Post by junon » Mon, Sep 22, 2025, 3:23 PM UTC

I disagree. Instead of anchors we had to rely on third party file change actions to only trigger jobs on certain file path changes, instead of using the built in mechanism, because each job required the list, and the list was long.

Using anchors would have improved the security of this, as well as the maintenance. The examples cited don't remotely demonstrate the cases where anchors would have been useful in GA.

I agree that YAML is a poor choice of format regardless but still, anchor support would have benefitted a number of projects ages ago.

Re: Dear GitHub: no YAML anchors, please

#40

Post by Spivak » Mon, Sep 22, 2025, 3:24 PM UTC

TheDong wrote: post #14

anttiharju wrote: post #7

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 qu…

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.

Just introduce a templating language and the CI to generate the yaml as part of your pipeline as way to make it simpler?

Above a certain level of complexity, sure. But having nothing in between is an annoying state of affairs. I use anchors in Gitlab pipelines and I hardly curse their names.