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

131–140 of 159 posts

Re: Dear GitHub: no YAML anchors, please

#131

Post by silverwind »

ok123456 wrote: post #106
jayd16 wrote: post #60

Earlier quoted context omitted.

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.

You don't have to reason about them. You write a compiler that enforces stronger invariants above and beyond everything is an array/string/list/number/pointer. Good general-purpose programming languages provide type systems that do just this. It is criminal that the industry simply ignores this and chooses to use blobs of YAML/JSON/XML with disastrous results---creating ad-hoc programming languages without a typesyst…

There is https://github.com/SchemaStore/schemastore which is effectively a type system for yaml/json.

Re: Dear GitHub: no YAML anchors, please

#132

Post by oblio »

freeplay wrote: post #111
rickette wrote: post #101

Earlier quoted context omitted.

GitHub Actions originally supported HCL (Hashicorp Configuration Language) instead of YAML. But the YAML force was too strong: https://github.blog/changelog/2019-09-17-github-actions-will... .

If you have worked with HCL in any serious capacity, you'll be happy they didn't go that route. Here's some fun examples to see why HCL sucks: - Create an if/elseif/else statement - Do anything remotely complex with a for loop (tip: you're probably going to have to use `flatten` a lot)

Stuff like HCL and Ansible YAML makes me want to require mandatory training in Ant contrib tasks for developers creating them:

https://ant-contrib.sourceforge.net/tasks/tasks/if.html

https://ant-contrib.sourceforge.net/tasks/tasks/for.html
Yes, programming with them was as fun as you're imagining.

Re: Dear GitHub: no YAML anchors, please

#133

Post by cyanydeez »

delusional wrote: post #52
jbjbjbjb wrote: post #38

Earlier quoted context omitted.

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

Gitlab does this locallyand i asdume in their cloud

Re: Dear GitHub: no YAML anchors, please

#134

Post by tarkaTheRotter »

0xbadcafebee wrote: post #129
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 o…

Hey. I'm currently making Typeflows to solve this (amongst) another few pain points, and am planning to make it available in JVM (this exists now)/TS and Python at least.

There are existing solutions around, but do miss out a bunch of things that are blatantly missing in the space:

- workflow visualisations (this is already working - you can see an example of workflow relationship and breakdowns on a non-trivial example at https://github.com/http4k/http4k/tree/master/.github/typeflo...);

- running workflows through an event simulator so you can tell cause and effect when it comes to what triggers what. Testing workflows anyone? :)

- security testing on workflows - to avoid the many footguns that there are in GHA around secrets etc;

- compliance tests around permitted Action versions;

- publishing of reusable repository files as binary dependencies that can be upgraded and compiled into your projects - including not just GHA actions and workflows but also things like version files, composable Copilot/Claude/Cursor instruction files;

- GitLab, CircleCI, Bitbucket, Azure DevOps support using the same approach and in multiple languages;

Early days yet, but am planning to make it free for OSS and paid for commercial users. I'm also dogfooding it on one of my other open source projects so to make sure that it can handle non-trivial cases. Lots to do - and hopefully it will be valuable enough for commercial companies to pay for!

Wish me luck!

https://typeflows.io/

Re: Dear GitHub: no YAML anchors, please

#135

Post by oblio »

ok123456 wrote: post #106
jayd16 wrote: post #60

Earlier quoted context omitted.

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.

You don't have to reason about them. You write a compiler that enforces stronger invariants above and beyond everything is an array/string/list/number/pointer. Good general-purpose programming languages provide type systems that do just this. It is criminal that the industry simply ignores this and chooses to use blobs of YAML/JSON/XML with disastrous results---creating ad-hoc programming languages without a typesyst…

> You write a compiler that enforces stronger invariants above and beyond everything is an array/string/list/number/pointer.

https://www.reddit.com/r/funny/comments/eccj2/how_to_draw_an...

Re: Dear GitHub: no YAML anchors, please

#136

Post by oblio »

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

Well, Groovy is a bit of a basket case programming language, so that doesn't help.

I say this as someone that built entire Jenkins Groovy frameworks for automating large Jenkins setups (think hundreds of nodes, thousands of Jenkins jobs, stuff like that).

Re: Dear GitHub: no YAML anchors, please

#137

Post by lukasmark744 »

oblio wrote: post #136
zft wrote: post #128

Earlier quoted context omitted.

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

Well, Groovy is a bit of a basket case programming language, so that doesn't help. I say this as someone that built entire Jenkins Groovy frameworks for automating large Jenkins setups (think hundreds of nodes, thousands of Jenkins jobs, stuff like that).

[dead]

Re: Dear GitHub: no YAML anchors, please

#138

Post by kazinator »

Common Lisp has this (and other dialects that imitate the Circle Notation; I think Scheme has it now, Emacs Lisp, TXR lisp, ):

E.g.

  (#1=(a b) c d e #1#)
encodes

  ((a b) c d e (a b))
where the two (a b) occurrences are one object. It can express circular structures:

  #1=(a b c . #1#)
encodes an infinite circular list

  (a b c a b c a b c ...)
The object to be duplicated is prefixed with #=. This associates the object with the integer. The integer is later referenced as ## to replicate it.

The thing is, you don't see a lot of this in human-written files, whether they are source code or data.

This is not the primary way that Lisp systems use for specifying replicated data in configurations, let alone code.

Substructure sharing occurs whether you use the notation or not due to interned symbols. (Plus compilers can deduplicate strings and such.) In (a a a) there is only one object a, a symbol.

If you feed the implementation circular source code though, ANSI CL says the behavior is undefined. Some interpreters can handle it under the right circumstances. In particular ones that don't try to do a full macro-expanding code walk before running the code. Compilers, not so much.

Re: Dear GitHub: no YAML anchors, please

#139

Post by jerjerjer »

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

> include

Interesting, although to me it looks more like a way to split one file into several (which is rather useful).

> extends

What's the difference with anchors? Looks the same, except works with include (and doesn't work with any other yaml tool).

> dynamic pipeline generation

Which is even harder to reason about compared to anchors, although certainly powerful.

Re: Dear GitHub: no YAML anchors, please

#140

Post by AaronAPU »

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 generate all my GH YAML files via Python. The thought of writing them by hand makes me want to vomit, one of the best design choices I ever made.
Post reply on HN