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

1–10 of 159 posts

Re: Dear GitHub: no YAML anchors, please

#2

Post by baobun »

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

Re: Dear GitHub: no YAML anchors, please

#4

Post by woodruffw »

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

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

Re: Dear GitHub: no YAML anchors, please

#7

Post by anttiharju »

I think YAML anchors in GitHub Actions are very welcome, for example for DRYing the push/pull_request 'paths:' filters [1].

Now only if they supported paths filter for `workflow_call` [2] event in addition to push/pull_request and my life would be a lot easier. Nontrivial repos have an unfortunate habit of building some sort of broken version of change detection themselves.

The limit of 20 unique workflow calls is quite low too but searching the docs for a source maybe they have removed it? It used to say

> You can call a maximum of 20 unique reusable workflows from a single workflow file.

but now it's max of 4 nested workflows without loops, which gives a lot of power for the more complex repos [3]. Ooh. Need to go test this.

[1] https://docs.github.com/en/actions/reference/workflows-and-a...

[2] https://docs.github.com/en/actions/reference/workflows-and-a...

[3] https://docs.github.com/en/actions/how-tos/reuse-automations...

Re: Dear GitHub: no YAML anchors, please

#8

Post by a_t48 »

Anchors will be exceptionally useful for a few workflows for me. We have what is essentially the same setup/teardown for three jobs within one workflow. I’d love to be able to factor that stuff out without introducing yet another yaml file to the repo, this will be a big help.

Re: Dear GitHub: no YAML anchors, please

#9

Post by qwerty2000 »

Just because it is expressed in YAML doesn't make YAML the party to blame here. I would say one of the main concerns I have with anything in GitHub Actions related to the word "merge" has to do with identifying the last commit for a merge, not merging of objects in YAML.

If you have two workflows... one to handle a PR creation/update and another to address the merge operation, it is like pulling teeth to get the final commit properly identified so you can grab any uploaded artifacts from the PR workflow.

Re: Dear GitHub: no YAML anchors, please

#10

Post by theamk »

Author'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 secret), then your choices are (a) copy-paste "env" block 3 times in each step, (b) use the new YAML anchor and (c) set secret at top-level scope. It is pretty clear to me that (c) is the worst idea, security wise - this will make secret available to every step in the workflow, making it much easier for malware to exfiltrate.

Post reply on HN