Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Pain That Is GitHub Actions

feldera.com

Post reply on HN
Print view View original

271–280 of 584 posts

Re: The Pain That Is GitHub Actions

#271

Post by dharmab »

motorest wrote: post #232
maratc wrote: post #160

Earlier quoted context omitted.

You can't put a breakpoint in YAML. You can't evaluate variables in YAML. You can't print debugging info from YAML. You can't rerun YAML from some point. YAML is great for the happy-flow where everything works. It's absolutely terrible for any other flow.

> You can't put a breakpoint in YAML. You can't evaluate variables in YAML. You can't print debugging info from YAML. You can't rerun YAML from some point It's a DSL. There is no execution, only configuration. The only thing that's executed are the custom scripts you create yourself, and any intro tutorial on the subject will eventually teach you that if you want to run anything beyond a single straight-forward comma…

> There is no execution, only configuration.

The YAML is fed into an agent which reads it to decide what to execute. Any time you change the control flow of a system by changing data, you are doing a form of programming.

Re: The Pain That Is GitHub Actions

#272

Post by DanielHB »

If you have complex multi-step actions I recommend tools like nx (for frontend projects) or Bazel. It massively simplifies caching parts of your CI workflows and works locally too.

We have a very complicated build process in my current project, but our CI pipelines are actually just a couple of hundred of lines of GHA yaml. Most of which are boilerplate or doing stuff like posting PR comments. The actual logic is in NX configuration.

Re: The Pain That Is GitHub Actions

#274

Post by JanMa »

mwenge wrote: post #222
JanMa wrote: post #112

Earlier quoted context omitted.

Whenever possible I now just use GitHub actions as a thin wrapper around a Makefile and this has improved my experience with it a lot. The Makefile takes care of installing all necessary dependencies and runs the relevant build/Test commands. This also enables me to test that stuff locally again without the long feedback loop mentioned in other comments in this thread.

Do you have a public example of this? I'd love to see how to do this with Github Actions.

Sure, here's one example: https://github.com/JanMa/nomad-driver-nspawn/blob/master/.gi...

Re: The Pain That Is GitHub Actions

#275

Post by no_wizard »

deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

Am I an outlier in that not only do I find GitHub actions pleasant to use, but that most folks over complicate their CI/CD pipelines? I've had to re-write alot of actions configurations over the last few years, and in every case, the issue was simply not thinking through the limits of the platform, or when things would be better to run as custom docker images (which you can do via GitHub Actions) etc.

It tends to be that folks want to shoehorn some technology into the pipeline that doesn't really fit, or they make these giant one shot configurations instead of running multiple small parallel jobs by setting up different configurations for different concerns etc.

Re: The Pain That Is GitHub Actions

#276

Post by cantagi »

hv42 wrote: post #266
xlii wrote: post #103

There is one thing that I haven’t seen mentioned: worst possible feedback loop. I’ve noticed this phenomenon few times already, and I think there’s nothing worse than having a 30-60s feedback loop. The one that keeps you glued to the screen but otherwise is completely nonproductive. I tried for many moons to replicate GHA environment on local and it’s impossible in my context. So every change is like „push, wait for…

With GitLab, I have found https://github.com/firecow/gitlab-ci-local to be an incredible time-saver when working with GitLab pipelines (similar to https://github.com/nektos/act for GitHub) I wish GitLab/GitHub would provide a way to do this by default, though.

act is great. I use it to iterate on actions locally (I self-host gitea actions, which uses act, so it's identical to github actions).

Re: The Pain That Is GitHub Actions

#277

Post by amtamt »

cnotv wrote: post #224
deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

Once, a reliable and wise colleague told me "Use in CI what you use locally" and that has been the best devop advice that never failed me to save my time. The second one has been, from someone else: if you can use anything else than bash, do that.

Try brainfuck...

Jokes aside... it's so trendy to bash bash that it's not funny anymore. Bash is still quite reliable for work that usually gets done in CI, and nearly maintenance free if used well.

Re: The Pain That Is GitHub Actions

#278

Post by vel0city »

raffraffraff wrote: post #113
HdS84 wrote: post #80

Earlier quoted context omitted.

There are lots of problems. Actions try to abstract the script away and give you a consistent experience and, must crucially, allow sharing. Because gitlab has no real way to share actions or workflows (I can do yaml include, but come on that sucks even harder than actions) you are constantly reinventing the wheel. That's ok if all you do is " build folder" but if you need caching, reporting of issues, code coverage…

I haven't looked too much into how sharing workflows works, but isn't the use of shared GitHub workflows (from outside your org) a little dangerous? I get it, we use other people's code all the time. Some we trust more (ISO of a Linux OS with SHA) and others we trust a little less even if it comes from a verified source with GPG, because we know that supply chain attacks can happen. Every time someone introduced a ne…

Definitely a mixed bag. Lots of community derived actions which yes, potentially have some bad supply chain questions. I tend to try and avoid these as much as possible. Lots of established vendors also have their own actions shared though, so you don't have to reinvent the wheel when interacting with their platforms/services/products.

For instance, AWS has a lot of actions they maintain to assist with common CI/CD needs with AWS services.

https://github.com/aws-actions

Re: The Pain That Is GitHub Actions

#279

Post by maratc »

motorest wrote: post #232
maratc wrote: post #160

Earlier quoted context omitted.

You can't put a breakpoint in YAML. You can't evaluate variables in YAML. You can't print debugging info from YAML. You can't rerun YAML from some point. YAML is great for the happy-flow where everything works. It's absolutely terrible for any other flow.

> You can't put a breakpoint in YAML. You can't evaluate variables in YAML. You can't print debugging info from YAML. You can't rerun YAML from some point It's a DSL. There is no execution, only configuration. The only thing that's executed are the custom scripts you create yourself, and any intro tutorial on the subject will eventually teach you that if you want to run anything beyond a single straight-forward comma…

Your attitude of "how is everyone so stupid" does not help the discussion.

> It's a DSL. There is no execution, only configuration.

Jenkins pipelines are also DSL. I still can print out debugging information from them. "It's a DSL" is not an excuse for being a special case of shitty DSL.

> any intro tutorial on the subject will eventually teach you

Do these tutorials have a chapter on what to do when you join a company with 500 engineers and a ton of YAMLs that are not written in that way?

> you should move those instructions to a shell script to make them testable

Yeah, no. How am I supposed to test my script that is supposed to run on Github-supplied runner with a ton of injected secrets and Github-supplied JSON of 10,000 lines, when I don’t have the runner, the secrets, or the JSON?

Re: The Pain That Is GitHub Actions

#280

Post by cantagi »

I have a problem with the Github Actions documentation. There is a lot of it, but it feels as though it was written from a "product" perspective, to explain how to use the product.

None of it usefully explains how GHA works from the ground up, in a way that would help me solve problems I encounter.

Post reply on HN