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

491–500 of 584 posts

Re: The Pain That Is GitHub Actions

#491

Post by DanielHB »

bluGill wrote: post #467
HeavyStorm wrote: post #427

Earlier quoted context omitted.

I totally prefer to have the ci break from time to time and be able to fix it than having the risk of it being broken and having no way of fixing it

The people who admin our CI system do a good job so it doesn't break, (well it does all the time, but onnetwork type errors not configuration - that is IT's fault not their fault.) The thing I want to change are things that I do in the build system so that it is checked in and previous versions when we need to build them (we are embedded where field failure is expensive so there are typically branches for the current…

In our CI we do a lot of clever stuff like posting comments to github PRs, sending messages on slack, etc. Even though those are useful things it makes the CI a bit harder to make changes to and test. Making it do more things also makes it a bit of a blackbox.

Re: The Pain That Is GitHub Actions

#492

Post by punkbit »

GitHub actions provide me the best experience I ever encountered when dealing with ops.

I pair it with bash scripts where I find important to run outside GitHub facilitating test and maintenance.

Although, I still find need to run multiple times or iterate over the actual GitHub action run time, which is a bit slow to iterate but find it best to catch any issues. If the dev feedback loop fixed it save me a lot of precious time. I know there’s a third party to run locally but it’s not the same…

Thus, bash scripting is great due to portability.

Re: The Pain That Is GitHub Actions

#493

Post by orthoxerox »

DanielHB wrote: post #317
mike_hearn wrote: post #314

Earlier quoted context omitted.

It peaked with Jenkins? I'm curious which CI platforms you've used. I swear by TeamCity. It doesn't seem to have any of these problems other people are facing with GitHub Actions. You can configure it with a GUI, or in XML, or using a type safe Kotlin DSL. These all actually interact so you can 'patch' a config via the GUI even if the system is configured via code, and TeamCity knows how to store config in a git repo…

I think people just hate CI set up by other people. I used TeamCity in a job a few years back and I absolutely hated it, however I imagine a lot of my hatred was the way it was set up. CI is just the thing no one wants to deal with, yet everyone wants to just work. And like any code or process, you need engineering to make it good. And like any project, you can't just blame bad tools for crappy results.

I think people just hate enterprise CI/CD. Setting up a pipeline for your own project isn't this hard and provides immediate value. But then you start getting additional requirements like "no touching your CI/CD code", "no using plugins except A, B or C" and "deployment must be integrated with Rally/Microfocus/another corporate change management system". Suddenly your pipelines become weird and brittle and feel like busywork.

Re: The Pain That Is GitHub Actions

#494

Post by punkbit »

jFriedensreich wrote: post #258

I am completely switching my mental model of what a ci/cd system should be at the moment: i use docker compose for absolutely everything possible. unit tests? runs as part of the container build. linear build dependent steps? multi stage docker biuld. DAG of build steps? dependencies in docker compose. This way every developer has the same system that ci/cd uses locally. debugging the dev setup is the same as debuggi…

Sounds like a good option. I’ll try something similar next time.

Re: The Pain That Is GitHub Actions

#495

Post by motorest »

int_19h wrote: post #484
motorest wrote: post #242

Earlier quoted context omitted.

> I use GH actions. You should treat it like all build systems: let them do what they are good at and nothing else. The rest should be shell scripts or separate docker containers. That's supposedly CICD 101. I don't understand why people in this thread seem to be missing this basic fact and instead they vent about irrelevant things like YAML. You set your pipeline. You provide your own scripts. If a GitHub Action sav…

If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions other than `run`?

> If the sole purpose of GitHub Actions is to run a few shell scripts in order, why does it have expression evaluation, conditions, and dozens of stock actions other than `run`?

For you to make that comment, I'm not sure you ever went through any basic intro to GitHub Actions tutorial.

GitHub Actions has 'run'.

https://docs.github.com/en/actions/writing-workflows/workflo...

Now that we established that, GitHub Actions also supports custom actions, which is a way to create, share, and reuse high-level actions. Instead of copy-pasting stuff around, you do the equivalent of importing a third party module.

https://docs.github.com/en/actions/sharing-automations/creat...

Onboarding a custom GitHub Action does not prevent you from using steps.run.

I don't even know where to start regarding your comment on expression evaluation and conditions. Have you used a CICD system before?

The problem with half the comments in this thread railing against CICD in general, YAML, etc is that they clearly do not have a faintest idea about what they are doing, and are instead complaining about ther own inability.

Re: The Pain That Is GitHub Actions

#496

Post by lewo »

jimbokun wrote: post #476
noplacelikehome wrote: post #442

Earlier quoted context omitted.

Nix is awesome for this -- write your entire series of CI tools in she'll or Python and run them locally in the exact same environment as they will run in CI. Add SOPS to bring secrets along for the ride.

Would Nix work well with GitHub Actions? Or is it more of a replacement? How do you automate running tests and deploying to dev on every push, for example?

> Would Nix work well with GitHub Actions?

You can use Nix with GitHub actions since there is a Nix GitHub action: https://github.com/marketplace/actions/install-nix. Every time the action is triggered, Nix rebuilds everything, but thanks to its caching (need to be configured), it only rebuilds targets that has changed.

> How do you automate running tests and deploying to dev on every push

Nix is a build tool and it's main purpose is not to deploy artifacts. There are however a lot of tools to deploy artifacts built by Nix: https://github.com/nix-community/awesome-nix?tab=readme-ov-f...

Note there are also several Nix CI that can do a better job than a raw GitHub actions, because they are designed for Nix (Hydra, Garnix, Hercules, ...).

Re: The Pain That Is GitHub Actions

#497

Post by ForTheKidz »

mike_hearn wrote: post #314
badloginagain wrote: post #294

Earlier quoted context omitted.

I hate the fact that CI peaked with Jenkins. I hate Jenkins, I hate Groovy, but for every company I've worked for there's been a 6-year-uptime Jenkins instance casually holding up the entire company. There's probably a lesson in there.

It peaked with Jenkins? I'm curious which CI platforms you've used. I swear by TeamCity. It doesn't seem to have any of these problems other people are facing with GitHub Actions. You can configure it with a GUI, or in XML, or using a type safe Kotlin DSL. These all actually interact so you can 'patch' a config via the GUI even if the system is configured via code, and TeamCity knows how to store config in a git repo…

> You can configure it with a GUI, or in XML, or using a type safe Kotlin DSL.

This is making me realize I want a CI with as few features as possible. If I'm going to spend months of my life debugging this thing I want as few corners to check as I can manage.

Re: The Pain That Is GitHub Actions

#498

Post by mcdeltat »

This is a fascinating read as someone who is currently working on migrating CI platforms. We deal with hundreds of internal repos where many CI platforms just don't scale well. We are probably going to choose Github Actions because it looks like the simplest, least-BS option. The problems the author mentions would be the least of our concerns.

Totally agree with other comments saying to keep as much logic out of CI config as possible. Many CI features are too convoluted for their own good. Keep it really simple. You can use any CI platform and have a shit time if you don't take the right approach.

Re: The Pain That Is GitHub Actions

#499

Post by mike_hearn »

dmuso wrote: post #409
mike_hearn wrote: post #314

Earlier quoted context omitted.

It peaked with Jenkins? I'm curious which CI platforms you've used. I swear by TeamCity. It doesn't seem to have any of these problems other people are facing with GitHub Actions. You can configure it with a GUI, or in XML, or using a type safe Kotlin DSL. These all actually interact so you can 'patch' a config via the GUI even if the system is configured via code, and TeamCity knows how to store config in a git repo…

Try doing a clean git clone in TeamCity. Nope, not even with the plugins that claim “clean clone” capability. You should be confident that CI can build/run/test an app with a clean starting point. If the CI forces a cached state on an agent that you can’t clear… TeamCity just does it wrong.

You just check the "delete files in checkout directory" box in the run screen. Are you thinking of something different? I've never had trouble doing a clean clone.

Re: The Pain That Is GitHub Actions

#500

Post by mike_hearn »

ForTheKidz wrote: post #497
mike_hearn wrote: post #314

Earlier quoted context omitted.

It peaked with Jenkins? I'm curious which CI platforms you've used. I swear by TeamCity. It doesn't seem to have any of these problems other people are facing with GitHub Actions. You can configure it with a GUI, or in XML, or using a type safe Kotlin DSL. These all actually interact so you can 'patch' a config via the GUI even if the system is configured via code, and TeamCity knows how to store config in a git repo…

> You can configure it with a GUI, or in XML, or using a type safe Kotlin DSL. This is making me realize I want a CI with as few features as possible. If I'm going to spend months of my life debugging this thing I want as few corners to check as I can manage.

I've never had to spend time debugging TeamCity setups. It's very transparent and easy to understand (to me, at least).

I tend to stick with the GUI because if you're doing JVM style work the complexity and tasks is all in the build you can run locally, the CI system is more about task scheduling so it's not that hard to configure. But being able to migrate from GUI to code when the setup becomes complex enough to justify it is a very nice thing.

Post reply on HN