'Dear GitHub: no YAML, please' would be a so much better title (content optional)
Dear GitHub: no YAML anchors, please
51–60 of 159 posts
Re: Dear GitHub: no YAML anchors, please
#52Can 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.
> prioritise being able to run them locally.
That is the key function any serious CI platform needs to tackle to get me interested. FORCE me to write something that can run locally. I'll accept using containers, or maybe even VMs, but make sure that whatever I build for your server ALSO runs on my machine.
I absolutely detest working on GitHub Actions because all too often it ends up requiring that I create a new repo where I can commit to master (because for some reason everybody loves writing actions that only work on master). Which means I have to move all the fucking secrets too.
Solve that for me PLEASE. Don't give me more YAML features.
Re: Dear GitHub: no YAML anchors, please
#53Earlier 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.
in what ways do they make static analysis harder? Don't they flatten out trivially after parsing?
The flattening out is the problem: most (all?) widely used YAML parsers represent the YAML document using the JSON object model, which means that there's no model or element representation of the anchors themselves.
That in turn means that there's no way to construct a source span back to the anchor itself, because the parsed representation doesn't know where the anchor came from (only that it was flattened).
Re: Dear GitHub: no YAML anchors, please
#54Can 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.
You could make a builder to do this for you. It could build your actions in a pre-commit hook or whatever.
Although, I think it is generally an accepted practice to use declarative configuration over imperative configuration? In part, maybe what the article is getting at, maybe?
Re: Dear GitHub: no YAML anchors, please
#55Can 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.
YAML is a serialization format. I like YAML as much as I like base64, that is I don't care about it unless you make me write it by hand, then I care very much.
GitHub Actions have a lot of rules, logic and multiple sublanguages in lots of places (e.g. conditions, shell scripts, etc.) YAML is completely superficial, XML would be an improvement due to less whitespace sensitivity alone.
Re: Dear GitHub: no YAML anchors, please
#56Earlier quoted context omitted.
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…
So GitHub shouldn't implement the spec because you personally don't like that the spec solves a problem you can optionally solve at another layer?
Re: Dear GitHub: no YAML anchors, please
#57Earlier quoted context omitted.
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. U…
Your team doesn't know YAML, it knows github actions. There's zero transferable knowledge when switching from github actions to kubernetes deployments, as there is precisely the same zero correlation between kubernetes and ansible configs. 'It's all YAML' is a lie and I'm continuously surprised so many people are falling for it for so long. YAML is the code-as-data, but the interpreter determines what it all means.
Re: Dear GitHub: no YAML anchors, please
#58Author's replacement for anchors is to use global syntax, like a top-level "env:" block. This is a terrible advice from security endpoint - given that env variables are often used for secrets data, you really _don't_ want them to set them at the top level. The secrets should be scoped as narrow as possible! For example, if you have a few jobs, and some of them need to download some data in first step (which needs a s…
I agree. OP’s statement ”the need to template environment variables across a subset of jobs suggests an architectural error in the workflow design” does not ring true for cases where you want developers to be able to quickly deploy a separate environment for each development branch, especially if said branch needs to connect to a matching backend/API/other service.
Re: Dear GitHub: no YAML anchors, please
#59A very pedantic point, but merge keys are not part of the YAML spec [1]! Merge keys are a custom type [2], which may optionally be applied during the construction phase of loading. I definitely wouldn't say that merge keys are integral to anchors.
(Also, as a personal bias, merge keys are really bad because they are ambiguous, and I haven't implemented them in my C++ yaml library (yaml-cpp) because of that.)
Re: Dear GitHub: no YAML anchors, please
#60Can 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.
Why do we think an arbitrary language is easier to reason about? If it was so easy you could just do it now. The yaml could be extremely simple and just call into your app, but most don't bother.
I'm certainly willing to believe that yaml is not the ideal answer but unless we're comparing it to a concrete alternative, I feel like this is just a "grass is always greener" type take.