Use the language you are already working in? Most languages have good YAML serialization and I think in most languages a function call taking a couple parameters that vary to produce slightly different but related objects is going to be as readable or more readable than YAML anchors.

▲

nirvdrum 7 hours ago | parent [-]

That would be better, but it's an option I already have available to me and it's just not attractive. AFAIK, GitHub Actions requires the config files to be committed. So, now I need to guard against someone making local modifications to a generated file. It's doable of course, but by the time I've set all this up, it would have been much easier for everyone to copy and paste the six lines of code in the three places they're needed. YAML anchors solve that problem without really creating any new ones.

If generating your GitHub Actions config from a programming language works for you, fantastic. I'm just happy we now have another (IMHO, attractive) option.

▲

WorldMaker 5 hours ago | parent [-]

Most of the debate here is that a lot of us don't find YAML anchors attractive. It can be one of the papercuts of using YAML.

I mostly agree with the article that with GitHub Actions specifically, I try to refactor things to the top-level "workflow" level first, and then yeah resort to copy and paste in most other cases.

I'm a little less adamant that GitHub should remove anchor support again than the original poster, but I do sympathize greatly, having had to debug some CircleCI YAML and Helm charts making heavy use of YAML anchors. CircleCI's YAML is so bad I have explored options to build it with a build process. Yeah, it does create new problems and none of those explorations got far enough to really improve the process, but one of the pushes to explore them was certainly that YAML anchors are a mess to debug, especially when you've got some other tool concatenating YAML files together and can result in anchor conflicts (and also other parts of the same YAML that depend on a particular form of how anchor conflicts overwrite each other, oof). I don't see GitHub Actions necessarily getting that bad just by enabling anchors, but I have seen enough of where anchors become a crutch and a problem.

	▲	nirvdrum 5 hours ago \| parent [-]
		That's fair. And I'm not arguing that YAML anchors can never be a problem. I am saying that layering in a whole custom build system to handle a 250 line ci.yml file is not the trade-off I'd make. What I'd hazard to say most teams do in that situation is duplicate config, which is not without its own problems. I think YAML anchors is a fine solution for these cases and don't think they'll lead to total chaos. Alas, not all config options can be hoisted to a higher level and I'm trusting a team has explored that option when it's available. If you're dealing with 10s of files that are 1000s of lines long, then YAML anchors may very well not be the ideal option. Having the choice lets each team find what works best for them.