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

141–150 of 159 posts

Re: Dear GitHub: no YAML anchors, please

#141

Post by everfrustrated »

Pxtl wrote: post #21
red_hare wrote: post #17

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.

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.

This so much this. Vscode has a very good syntax check github actions yaml so it's not yaml that's the problem.

It's the workflow for developing pipelines that's the problem. If I had something I could run locally - even in a debug dry-run only form that would go a long way to debugging job dependencies, etc. Testing failure cases flow conditional logic in the expected manner etc.

Re: Dear GitHub: no YAML anchors, please

#142

Post by devmor »

nirvdrum wrote: post #24
devmor wrote: 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.

Sorry, I think my comment was not clear.

I think allowing both setting and reading of variables directly in the configuration file is a problem.

Not reading variables that have been set outside of the configuration file alone.

Re: Dear GitHub: no YAML anchors, please

#143

Post by everfrustrated »

a456463 wrote: post #102
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".

As some one that has written massive gitlab pipelines for monoliths and super tiny ones and on boarded teams, YAML anchors are amazing.

Agreed. Anchors is YAMLs real feature. YAML without anchors is just JSON + comments otherwise.

Re: Dear GitHub: no YAML anchors, please

#144

Post by [deleted] »

baq wrote: post #104
ZYbCRq22HbJ2y7 wrote: post #54

Earlier quoted context omitted.

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?

YAML is neither declarative nor imperative. It's just a tree (or graph, with references) serialization to text.

[deleted]

Re: Dear GitHub: no YAML anchors, please

#145

Post by ZYbCRq22HbJ2y7 »

baq wrote: post #104
ZYbCRq22HbJ2y7 wrote: post #54

Earlier quoted context omitted.

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?

YAML is neither declarative nor imperative. It's just a tree (or graph, with references) serialization to text.

I didn't say anything about YAML? Also, I think the term "declarative configuration" has drifted to mean different things over time depending on where it is used.

Re: Dear GitHub: no YAML anchors, please

#146

Post by plqbfbv »

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.

In my experience include/extends works well for importing or extending whole jobs, but not so much for defining a small snippet of text that I want to reuse across many jobs, perhaps when overriding stuff.

An example of how I normally use them and why I still find them useful:

  # Imports whole pipeline architecture jobs
  include:
  - project: company/ci-templates
    ref: "master"
    file: "languages/stack.yaml"
  
  # Define a command I need to use exactly the same
  # across different jobs I'm going to override
  .vpn_connect: &vpn_connect
    - cmd1
    - cmd2
    - cmd3 &
  
  job1:
    extends: imported1
    script:
      - ....
      - *vpn_connect # 2nd command
      - ...
  
  job2:
    extends: imported2
    script:
      - ...
      - ...
      - *vpn_connect # 3rd command
      - ...

Re: Dear GitHub: no YAML anchors, please

#147

Post by eadmund »

oblio wrote: post #132
freeplay wrote: post #111

Earlier quoted context omitted.

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.

That looks so terrible, but they could have been so easily transformed into an S-expression language similar to Lisp:

    (if (equals foo "bar")
      (then (echo "The value of property foo is 'bar'"))
      (elseif (equals foo "foo")
        (then (echo "The value of property foo is 'bar'")))
      (else (echo "The value of property foo is not 'foo' or 'bar'")))
That’s not a Lisp-like language I particularly like, but it’s not flat-out insane like Ant appears to be.

Advocates for the inappropriate use of XML (basically, anywhere it was used as anything other than a markup language) have lot to answer for.

Re: Dear GitHub: no YAML anchors, please

#149

Post by Charon77 »

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…

Just run the code and see the output.

There are multiple ways to safely run untrusted code.

I for one enjoy how build.rs in rust does it: you have a rust code that controls the entire build system by just printing stuffs on stdout.

There are other ways of course

Re: Dear GitHub: no YAML anchors, please

#150

Post by biimugan »

Charon77 wrote: post #149
biimugan wrote: post #116

Earlier quoted context omitted.

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…

Just run the code and see the output. There are multiple ways to safely run untrusted code. I for one enjoy how build.rs in rust does it: you have a rust code that controls the entire build system by just printing stuffs on stdout. There are other ways of course

Just run the code that provisions the infrastructure? Sandboxing is the least of your problems. You would need to fully mock out all function executions and their results to have a hope to properly execute the code let alone govern what's happening without affecting a live environment. And even still, there would be ways to fool this kind of introspection, as I mentioned. In an enterprise environment where this kind of governance is mandatory, that's not acceptable.

In any case, regardless whatever clever method you try to use, even if you're successful, it's not as straightforward and easily understood and extensible as OPA policy. Let's say you succeed in governing Rust code. OK, but now I have developers who are writing in Python and Java and TypeScript. What now? Develop a new, customized solution for each one? No thanks

Post reply on HN