Repository navigation
Support YAML Anchors #1182
Description
Note to incoming readers (2025)
I will update this if anything changes, you don't need to read this entire thread.
Update August 2025
Update March 2025
@salilsub, a GitHub Staff member, has said that this is coming in the latter half of 2025!!
Update Jan 2025
@salilsub started a Poll Comment to request interest in one of three proposed solutions.
🎉 : I need YAML anchors per the YAML spec
🚀 : I need a way to write YAML once and re-use it. I don't need YAML anchors specifically, but I need to have a way to do this in the same file as my workflow
👀 : I need a way to write YAML once and re-use it in my workflows. I can use either the same file or a different file I import. I really need templating (like the kind available in Azure DevOps Pipelines)
A deadline for the poll has been set for the end of February. Personally, I think this poll is an inappropriate response this this issue.
Update Aug 2024
This comment from staff says they will be looking at this next year
Thanks for engaging on this all, this is on our list to get to in the early part of next year. Right now we are re-working the services in Actions which do our YAML expansion (focusing on how we improve their availability). Once we are live with the new services we will start looking at adding features and this is on our list <3
How Can I Help?
If you want to help, upvote this comment by reacting to it with 👍. This will help it sort higher in the issues list.
Adding "me too" or "+1" comments does not help. Issues are not sorted by the number of comments, they are sorted by the number of reactions to the top issue comment (this comment). The only thing you accomplish by adding "me too", or "+1" is to send an email to issue subscribers (the other people who have commented, not staff). This will not help the issue get done faster, and may cause users to unsubscribe from this issue, reducing visibility. Comments are already being collapsed, please don't add noise to the signal.
Original Issue
Describe the enhancement
Support YAML anchors in in workflow files
Code Snippet
- env: &docker_cred
DOCKER_USER: ${{ secrets.DOCKER_USER }}
DOCKER_PASS: ${{ secrets.DOCKER_PASS }}
# ...
- env:
<<: *docker_credOR
anchors:
docker_hub_credentials: &docker_hub_credentials
credentials:
username: my-dockerhub-username
password: ${{ secrets.DOCKER_HUB_PASSWORD }}
postgres_service: &postgres_service
postgres:
image: mdillon/postgis:9.6
<<: *docker_hub_credentialsAdditional information
This has been asked for before, in other places
Note to implementors
This is generally handled by YAML parsers automatically. Perhaps it has been disabled, or a parser that does not support it is being used. This might be as simple as switching YAML parsers.
Activity
freitasmurillo commentedon Aug 17, 2021
3+ years of people complaining and u don't take any action?
Either, say u won't do or do it already. not a big deal to implement.
DanySK commentedon Sep 2, 2021
This is truly absurd. I think that, given the existence of so many YAML parsers, it is harder to not support anchors and merge keys than doing it. Just let a normal YAML parser run.
kyeotic commentedon Sep 2, 2021
@DanySK (and to a lesser degree @freitasmurillo), while I appreciate the support on issues, since upvotes help show priority, I don't think hurling abuse at the maintainers or anyone else is going to get this done any faster. If either of you are professional software developers I'm sure you can relate to working on project's whose feature requests exceed your team's bandwidth. There are 300 open issues on this repository and some of them describe actual bugs. Surely this is not the highest priority ticket.
Please keep in mind there is a human on the other side reading these messages. Consider how you might react to someone who said as much to you.
DanySK commentedon Sep 2, 2021
Hi @kyeotic,
I have no intention to be rude to people, much less to those whose work benefits the FOSS community so much. I expressed a technical concern that is puzzling me from a software engineering perspective, and that you also highlighted in the first post. I did not think that could hurt others -- usually, there is either some deep issue behind it, or it could just be a matter of applying small correctives.
That said, yes I know that it's impossible to keep up with the pace of feature requests in many cases, and especially so for FOSS. Given that, if someone can help me figure out where the YAML parsing happens, I'm willing to help.
midgleyc commentedon Sep 20, 2021
The error message appears in YamlObjectReader.cs which references
YamlDotNet.Core(and thecsprojreferences version5.3.0), so I expect that's the parser.They're a few major versions behind, but it looks like there are bugs even on the latest version, e.g. this one from August. I'm not sure if that can be ignored, because they're not using the serialization from
YamlDotNet, only the parser, and they've written their own custom code on top of the library.So in short, I think it's a custom parser, written on top of another parser. The parser looks very local in how it parses things, so supporting anchors might require a bit of a rearchitect, which would explain why it's been open for so long.
freitasmurillo commentedon Oct 15, 2021
@kyeotic sorry for being late to get your response. I definitely wasn't abusing anyone, sorry if that is what it sounded.
Not having English as my primary language probably helped a lot. 😞
What I was trying to convey is that 3 years without replying seemed to me a lot, u know?
This feature would be amazing and I know that they have a lot but I think once in a while they could provide updates and let people know what is on their plate or not for the moment.
If they don't have a minimal clue on if they will do or not post it on the thread. 💥
freitasmurillo commentedon Oct 15, 2021
For the feature request POV I am more than happy to help anyhow.
aramfe commentedon Nov 9, 2021
As much as we love GitHub Actions, the lack of this really makes us think about to switch back to GitLab. Re-using steps shouldn't be that complicated to work with (composite actions, etc. aren't really comparable to in-file templates).
Right now, GitHub doesn't seem to focus on their enterprise and power users, which need to work with complex workflows. It's understandable, as GitHub is very much more driven by the open-source community, but it nevertheless doesn't change the fact, that a lack of something like this, is very frustrating for enterprise users.
It simply makes it hideous to build complex workflows without a feature like that, even though GitHub has the best fundaments for building complex workflows in comparison to any other CI/CD platform.
When we evaluated both, GitHub and GitLab, we always expected in-file templating support to be released very soon for GitHub and that's why we never really considered the lack of this, as a decision defining point in the outcome of our evaluation. But looking back to it from today, it would have definitely changed the outcome of our evaluation, without any doubt.
GitLab CI / CD supports this since more than like three years already, and I haven't seen anyone, who didn't use it for their pipeline definition files. In recent time, they supported this without any anchors, which made it even easier to work with.
I would really love to see this being supported here as well.
umarcor commentedon Nov 19, 2021
@aramfe, your wording seems to imply that enterprise and power users have more complex requirements than the open-source community. I'd say that most enterprise and power users in GitHub are producing open-source software. Thus, that's a false dicotomy.
kyeotic commentedon Nov 20, 2021
I don't know if you have any data to back this up, but I would be very, very surprised to learn that this was true. I expect most enterprises, even those using GitHub, to be developed closed-source, proprietary software.
umarcor commentedon Nov 20, 2021
@kyeotic it's an opinion, based on the enterprises I know which use GitHub. Nevertheless, the point holds regardless of quantitative data: licensing of a software project is unrelated to the complexity. Moreover, the difference between enterprise users and others is that enterprise clients pay GitHub, not the licenses they use or the complexity of their projects.
mehran-sayyah commentedon Nov 30, 2021
Ok
umarcor commentedon Nov 30, 2021
FTR:
mithro/actions-includes allows to work around the lack of YAML anchor support, by preprocessing Workflow files.
Alternatively, in hdl/containers, a Reusable Workflow is combined with a Python script in order to dynamically generate the
matrixby processing a YAML file with anchors.jobs)keyto decide which job matrix to generate: boolector.yml.A similar approach is used in the
ParamsReusable Workflow of pyTooling/Actions: Params.yml.mehran-sayyah commentedon Dec 1, 2021
#1059
216 remaining items
sonphan12 commentedon Aug 13, 2025
So without merge key, are there any ways, even workarounds, to achieve what I am trying to achieve above using anchor? 🤔
kyeotic commentedon Aug 13, 2025
Hey gang, this issue is closed. If you are having issues with the YAML anchors feature its best to open a new issue. If its a real bug, it will need a new issue to track fixing it.
steveoh commentedon Aug 13, 2025
I've been enjoying reading and learning from these comments. A discussion topic would be a great place to continue those discussions if this issue is no longer the desired place. Please provide a link for me to watch.
ci(update): use yaml anchor/aliases
ci(update): use yaml anchor/aliases
Merge #1719: ci: DRY workflow using anchors
mosakhan21452-afk commentedon Jan 16, 2026
polarathene commentedon Jan 29, 2026
For anyone interested, as it was requested in earlier comments a few times to open a separate issue/discussion and it doesn't seem like anyone else has done that yet, I've created a feature request for merge keys support (aka
<<: *some-ref).n0099 commentedon Feb 19, 2026
Dear GitHub: no YAML anchors, please
GitHub Actions finally supports YAML anchors (but not really)
ci(e2e): add DIRECT_URL env (required by schema.prisma datasource)
ci(e2e): add DB_* env vars for pg native client (seed SASL fix)
docs(ci-gate): document node-properties residual risk, not fixed (clo…
ci(e2e): define the shard list once and verify it in its own job
ci: dedupe the PostGIS services and the package job's artifact downloads
docs(core): the phase 13 action contract — the adversarial review's f…