Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear GitHub: no YAML anchors, please

blog.yossarian.net

Post reply on HN
Print view View original

41–50 of 159 posts

Re: Dear GitHub: no YAML anchors, please

#41

Post by nirvdrum »

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.

Having used CI systems and application frameworks that support YAML anchors for configuration, adding in a programming language would be a massive amount of complexity for very little gain. We're not talking about dozens of locations with hundreds of lines of shared code.

Asking the team to add a new build dependency, learn a new language, and add a new build step would create considerably more problems, not fewer. Used sparingly and as needed, YAML anchors are quite easy to read. A good editor will even allow you to jump to the source definition just as it would any other variable.

Being self-contained without any additional dependencies is a huge advantage, particularly for open source projects, IMHO. I'd wager very few people are going to learn Dhall in order to fix an issue with an open source project's CI.

Re: Dear GitHub: no YAML anchors, please

#42

Post by OJFord »

Ok, now make the 'redundancy' argument with anything other than `env` or `permissions`.

I think they should be supported because it's surprising and confusing if you start saying 'actually, it's a proprietary subset of YAML', no more reason needed than that.

Re: Dear GitHub: no YAML anchors, please

#43

Post by giancarlostoro »

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.

Wouldn't Terraform solve this? You can have all your infrastructure as code in a git repo.

Re: Dear GitHub: no YAML anchors, please

#44

Post by detaro »

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.

in what ways do they make static analysis harder? Don't they flatten out trivially after parsing?

Re: Dear GitHub: no YAML anchors, please

#45

Post by woodruffw »

willseth wrote: post #26
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.

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.

To be clear, I understand why people want to use anchors. The argument isn't that they aren't useful: it's that the juice is not worth the squeeze, and that GitHub's decision to support them reflects a lack of design discretion.

Or in other words: if your problem is DRYness, GitHub should be fixing or enhancing the ~dozen other ways in which the components of a workflow shadow and scope with each other. Adding a new cross-cutting form of interaction between components makes the overall experience of using GitHub Actions less consistent (and less secure, per points about static analysis challenges) at the benefit of a small amount of deduplication.

Re: Dear GitHub: no YAML anchors, please

#46

Post by phanimahesh »

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.

This. So true. Yaml has always been an overly complicated format, with weird quirks ( like norway becoming false in a list of country codes ).

I find it an absolute shame that languages like Dhall did not become more popular earlier. Now everything in devops is yaml, and I think many developers pick yaml configs not out of good reasons but defaulting to its ubiquity as sufficient.

Re: Dear GitHub: no YAML anchors, please

#47

Post by wiether »

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.

Basically what we ended up doing at work is creating some kind of YAML generator.

We write Bash or Python, and our tool will produce the YAML pipeline reflecting it.

So we dont need to maintain YAML with over-complicated format.

The resulting YAML is not meant to be read by an actual human since its absolute garbage, but the code we want to run is running when we want, without having to maintain the YAML.

And we can easily test it locally.

Re: Dear GitHub: no YAML anchors, please

#48

Post by imiric »

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.

Agreed. YAML is not a great format to begin with, but using it for anything slightly more sophisticated (looking at you Ansible, k8s, etc.) is an exercise in frustration.

I really enjoyed working with the Earthfile format[1] used for Earthly CI, which unfortunately seems like a dead end now. It's a mix of Dockerfile and Makefile, which made it made very familiar to read and write. Best of all, it allowed running the pipeline locally exactly as it would run remotely, which made development and troubleshooting so much easier. The fact GH Actions doesn't have something equivalent is awful UX[2].

Honestly, I wish the industry hadn't settled on GitHub and GH Actions. We need better tooling and better stewards of open source than a giant corporation who has historically been hostile to open source.

[1]: https://earthly.dev/earthfile

[2]: Yes, I'm aware of `act`, but I've had nothing but issues with it.

Re: Dear GitHub: no YAML anchors, please

#49

Post by ericHosick »

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.

Yes! Hopefully a language that supports code as data (homoiconicity).

Re: Dear GitHub: no YAML anchors, please

#50

Post by ivanjermakov »

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.

Notable mentions are Zig build system and nob: https://github.com/tsoding/nob.h.
Post reply on HN