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

121–130 of 159 posts

Re: Dear GitHub: no YAML anchors, please

#121

Post by nirvdrum »

WorldMaker wrote: post #114
nirvdrum wrote: post #90

Earlier quoted context omitted.

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…

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…

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.

Re: Dear GitHub: no YAML anchors, please

#122

Post by nirvdrum »

theamk wrote: post #87
nirvdrum wrote: post #41

Earlier quoted context omitted.

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…

> not talking about dozens of locations with hundreds of lines of shared code. :) :) :) .github/workflows in my current project: 33 files, 3913 lines total, 1588 lines unique. (and this was _after_ we moved all we can into custom actions and sub-workflows)

Ouch. That sounds terrible with or without YAML anchors. GitHub Actions has overall been a great addition, allowing projects to integrate CI directly into their PR process. But, I never understood why it didn't have simpler paths for the very common use cases of CI and CD. Virtually any other dedicated CI product is considerably easier to bootstrap.

Re: Dear GitHub: no YAML anchors, please

#123

Post by catlifeonmars »

biimugan wrote: post #116
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.

I agree somewhat with the proposition that YAML is annoying for configuring something like a workflow engine (CI systems) or Kubernetes. But having it defined in YAML is actually preferable in an enterprise context. It makes it trivial to run something like OPA policy against the configuration so that enterprise standards and governance can be enforced. When something is written in a real programming language (that d…

> If the system consuming the YAML supports in-band signalling -- i.e. proprietary non-YAML directives -- then you would need to first normalize the YAML using that system to interpret and expand those signals.

cough CloudFormation cough

Re: Dear GitHub: no YAML anchors, please

#124

Post by verdverm »

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.

I use CUE and generate the yaml, don't care what a giant unreadable slop it is anymore

I use CUE to read yamhell too

Re: Dear GitHub: no YAML anchors, please

#125

Post by verdverm »

woodruffw wrote: post #45
willseth wrote: post #26

Earlier 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…

> GitHub's decision to ... reflects a lack of design discretion.

So true, not the first time, not the last time.

I'm at the point of exploring Gerrit as an alternative

Re: Dear GitHub: no YAML anchors, please

#126

Post by jerjerjer »

I don't think anchors' primary function is to allow global definitions (of variables or whatever), rather it's more like arbitrary templates/snippets to be reused through the YAML file.

In GitLab, where YAML anchors have been supported for years, I personally find them very useful —it's the only way of "code" reuse, really. In GitLab there's a special edtor just for .gitlab-ci.yml, which shows the original view and the combined read-only view (with all anchors expanded).

I agree that it's hard to point to the specific line of the source code, but it's enough — in case of an error — to output an action name, action property name, and actual property value that caused an error. Based on these three things, a developer can easily find the correct line.

Re: Dear GitHub: no YAML anchors, please

#127

Post by zft »

jerjerjer wrote: post #126

I don't think anchors' primary function is to allow global definitions (of variables or whatever), rather it's more like arbitrary templates/snippets to be reused through the YAML file. In GitLab, where YAML anchors have been supported for years, I personally find them very useful —it's the only way of "code" reuse, really. In GitLab there's a special edtor just for .gitlab-ci.yml, which shows the original view and t…

>it's the only way of "code" reuse, really.

not really. You can also use include/extends pattern. If that is not enough, there is dynamic pipeline generation feature.

Re: Dear GitHub: no YAML anchors, please

#128

Post by zft »

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.

jenkins supports groovy dsl jobs. I would not say using it made anything easier

Re: Dear GitHub: no YAML anchors, please

#129

Post by 0xbadcafebee »

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.

A custom language in GHA would be worse. You'd be limited by whatever language they supported, and any problems with it would have to go through their support team. It adds more burden on GHA (they spending more time/money on support) without creating value (new features you want).

You already don't have to use YAML. Use whatever language you want to define the configuration, and then dump it as YAML. By using your own language and outputting YAML, you get to implement any solution you want, and GitHub gets to spend more cycles building features.

Simple example:

  1. Create a couple inherited Python classes
  2. Write class functions to enable/disable GHA features and validate them
  3. Have the functions store data in the class object
  4. Use a library to output the class as YAML
  5. Now craft your GHA config by simply calling a Python object
  6. Run code, save output file, apply to your repo
I don't know why nobody has made this yet, but it wouldn't be hard. Read GHA docs, write Python classes to match, output as YAML.

If you want more than GHA features support [via configuration], use the GHA API (https://docs.github.com/en/rest/actions) or scripted workflows feature (https://github.com/actions/github-script).

Re: Dear GitHub: no YAML anchors, please

#130

Post by [deleted] »

zft wrote: post #128
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.

jenkins supports groovy dsl jobs. I would not say using it made anything easier

[deleted]
Post reply on HN