Live data from Hacker News

Dear GitHub: no YAML anchors, please

blog.yossarian.net

21–30 of 159 posts

Re: Dear GitHub: no YAML anchors, please

#21

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

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.

Re: Dear GitHub: no YAML anchors, please

#24
post #13

Obviously they are very useful. I still don't think they should exist in this usage of yaml. Once you allow setting and reading of variables in a configuration file, you lose the safety that makes the format useful. You might as well be using a bash script at that point.

You already can set and read variables. The `matrix` section is often used to test against multiple versions of software. Environment variables can be referenced. And the project configuration supports both secrets and variables configured at the project level.

Re: Dear GitHub: no YAML anchors, please

#25

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

> 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 a human probably intended, huh?

Re: Dear GitHub: no YAML anchors, please

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

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.

Re: Dear GitHub: no YAML anchors, please

#27

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

Re: Dear GitHub: no YAML anchors, please

#28

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

Easy to write and read until it gets about a page or two long. Then you have to figure out stuff like "Oh gee, I'm no nesting layer 18, so that's... The object.... That is.... The array of.... The objects of....."

Plus it has exactly enough convenience-feature-related sharp edges to be risky to hand to a newbie, while wearing the dress of something that should be too bog-simple to have that problem. I, too, enjoy languages that arbitrarily decide the Norwegian TLD is actually a Boolean "false."

Re: Dear GitHub: no YAML anchors, please

#29
post #25

Earlier quoted context omitted.

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.

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

Re: Dear GitHub: no YAML anchors, please

#30

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

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.
Post reply on HN