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

▲

saurik 7 hours ago | parent [-]

"YAML" should mean something. When I saw GitHub Actions supported "YAML", I thought "OK, certainly not my favorite, but I can deal with that", and so I read the YAML specification, saw anchors, and then had to realize the hard way that they didn't work on GitHub Actions, leaving me unsure what even would or wouldn't work going forward. Is this even the only way it differs? I don't know, as they apparently don't use YAML :/.

This also means that, if you use an off-the-shelf implementation to parse these files, you're "doing it wrong", as you are introducing a parser differential: I can put code in one of these files that one tool uses and another tool ignores. (Hopefully, the file just gets entirely rejected if I use the feature, but I do not remember what the experience I had was when I tried using the feature myself; but, even that is a security issue.)

> Except: GitHub Actions doesn’t support merge keys! They appear to be using their own internal YAML parser that already had some degree of support for anchors and references, but not for merge keys.

Well, hopefully they also prioritize fixing that? Doing what GitHub did, is apparently still doing, and what you are wanting them to keep doing (just only in your specific way) is not actually using "YAML": it is making a new bespoke syntax that looks a bit like YAML and then insisting on calling it "YAML" even though it isn't actually YAML and you can neither read the YAML documentation nor use off-the-shelf YAML libraries.

Regardless, it sounds like your tool already supports YAML anchors, as your off-the-shelf implementation of YAML (correctly) supports YAML anchors. You are upset that this implementation doesn't provide you source map attribution: that was also a problem with C preprocessors for a long time, but that can and should be fixed inside of the parser, not by deciding the language feature shouldn't exist because of library limitations.

	▲	kiitos 7 hours ago \| parent \| next [-]
		> and so I read the YAML specification but there isn't a single YAML spec, there are at least 2 in common use: yaml 1.1, and 1.2, which have discrete specs and feature-sets. re: anchor stuff specifically, 1.1 supports merge keys whereas 1.2 explicitly does not, so that's one thing and github actions does not actually specify which yaml spec/version it uses when parsing workflow yaml files it's unfortunately just not the case that "YAML means something" that is well-defined in the sense that you mean here
	▲	woodruffw 7 hours ago \| parent \| prev [-]
		> "YAML" should mean something. Sure, agreed. Another comment notes that GitHub probably should call this their own proprietary subset of YAML, and I wouldn't object to that. > Well, hopefully they also prioritize fixing that? I expect they won't, since it's not clear what version of YAML they even aim to be compatible with. However, I don't understand why engineers who wouldn't jump off of a bridge because someone told them to would follow a spec to the dot just because it exists. Specifications are sometimes complicated and bad, and implementing a subset is sometimes the right thing to do! GitHub Actions, for example, doesn't make use of the fact that YAML is actually a multi-document format, and most YAML libraries don't gracefully handle multiple documents in a single YAML stream. Should GitHub Actions support this? It's entirely unclear to me that there would be any value in them doing so; subsets are frequently the right engineering choice.