-
Notifications
You must be signed in to change notification settings - Fork 936
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support YAML Anchors #1182
Comments
3+ years of people complaining and u don't take any action? |
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. |
@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. |
Hi @kyeotic, 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. |
The error message appears in YamlObjectReader.cs which references 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 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. |
@kyeotic sorry for being late to get your response. I definitely wasn't abusing anyone, sorry if that is what it sounded. What I was trying to convey is that 3 years without replying seemed to me a lot, u know? If they don't have a minimal clue on if they will do or not post it on the thread. 💥 |
For the feature request POV I am more than happy to help anyhow. |
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. |
@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. |
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. |
@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. |
Ok |
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
A similar approach is used in the |
would love to have anchor support in github workflow files as well :) |
I agree, we need to do this. In the meantime, we've made a number of improvements in simplifying complex workflows, like adding reusable workflows. There are some tricky bits about this implementation - as we have multiple components that deal with workflows (it's not just the runner in this repo) - but this is on the backlog. I don't have an ETA, but yes, we will do this. Thanks everybody for the feedback. |
This is a desperately needed feature. |
+1 |
Please stop adding "me too" and "plus one" comments. They do not help, all they do is send an email to all the other people in this thread. If you want to help, upvote the original comment. |
This is a lost case anyways.. |
Neither is useful, let's be honest. But at least the pinging brings some hope to this world. And having such a long case without any action from the dev team can prevent poor souls from jumping into using GH actions. |
"me too" comments do not bring hope to me, because I know GitHub staff are not seeing them. Actually, they just remind me how unlikely this issue is to be fixed, by bringing my attention back to the issue. My attention here is not useful to anyone. They are unlikely to deter anyone more than the mere fact that this issue is 3 years old, especially considering they will just get hidden in the "more items" fold. If you don't think upvoting is useful, then just move on. This issue is a graveyard, let the dead sleep. |
GitHub mostly just looks at their community feedback discussions page so I don't think there's even much point in this issue - if you want your voice to have a higher chance of being seen (and heard) then you should upvote/comment on the relevant discussion instead: |
Sounds cute in theory, but GitHub completely ignores the second most upvoted discussion in the history of the platform. The problem is that nobody at GitHub cares. So we can rant wherever we want, they'll swiftly mute us then rush to get a promotion by shoving a new AI powered something in our face. |
The feedback discussions are not actively monitored as well. I don't blame them - the amount of threads per day is insane. Regarding the YAML anchors: There were several comments from employees, stating that this feature most likely never gets implemented due to technical constraints introduced by their current architecture (something about the way these workflow files are fetched and interpreted). |
Are we redditing over github issues, perchance? |
Problem
pull_request:
branches:
- develop
- feature/**
- bugfix/**
- main
paths:
- '3.11/**'
- '.github/workflows/python-3.11-docker-image-cicd.yaml'
push:
branches:
- develop
- feature/**
- bugfix/**
- main
tags:
# PRD environment: once we decide on tagging the pipeline with a semantic version. Placed on master branch
- 'v*'
# https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-including-paths
paths:
- '3.11/**'
- '.github/workflows/python-3.11-docker-image-cicd.yaml' Achors support
# Proposed support with a prefixed `g-` object like Docker
g-on-branches-and-paths: &on-branches-and-paths
branches:
- develop
- feature/**
- bugfix/**
- main
paths:
- '3.11/**'
- '.github/workflows/python-3.11-docker-image-cicd.yaml'
# Regular Github workflow object tree
on:
pull_request: *on-branches-and-paths
push: *on-branches-and-paths |
This goes further with splitting out different jobs, by listing the Appraisals in the matrix. The hope is that this will provide better feedback when parts of the build fails, as if we've got something like a flakey test, it should run against every combination. In addition to this, it extracts a "composite" action which allows for some reuse between different jobs. It's not possible to reuse the services section, unfortunately (YAML anchors aren't supported, which would be the ideal solution). https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs https://docs.github.com/en/actions/creating-actions/creating-a-composite-action actions/runner#1182
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 |
Wow thats good news after such a long wait. Thanks for keeping us up to date @nebuk89 🙂 |
sure ill add to the issue mentioned list on this, why not :) actions/runner#1182
Note to incoming readers (2024)
This issue has been open for several years, and despite commitment from staff that it would be done there has been no progress.I will update this if anything changes, you don't need to read this entire thread.UPDATE Aug 2024: The latest comment from staff says they will be looking at this next year
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, it does not get seen by GitHub staff.
Original Issue
Describe the enhancement
Support YAML anchors in in workflow files
Code Snippet
OR
Additional information
This has been asked for before, in other places
Note to implementors
The text was updated successfully, but these errors were encountered: