Live data from Hacker News

I'll think twice before using GitHub Actions again

ninkovic.dev

81–90 of 284 posts

Re: I'll think twice before using GitHub Actions again

#81

Why is this team sticking multiple directories that are “independent of each other” into a single repository? This sounds like a clear case of doing version control wrong. Monorepos come with their own set of challenges, and I don’t think there are many situations where they’re actually warranted. They certainly don’t help for completely independent projects.

Yeah, sounds like the problems are more due to monorepos rather than with GitHub actions. Seems like the pendulum always swings too far. Overdoing microservices results in redundant code and interservice spaghetti. Monorepos have their own set of issues. The only solution is to think carefully about a what size chunk of functionality you want to build, test, and deploy as a unit.

Re: I'll think twice before using GitHub Actions again

#82

I tried to use GitHub Actions on Forgejo and... It's so much worse than using an actual CI pipeline. With Woodpecker/Jenkins you know exactly what your pipeline is doing. With GitHub actions, not even the developers of the actions themselves know what the runner does.

> use GitHub Actions on Forgejo

What does this even mean? Are you talking about Forgejo Actions, or are you somehow hosting your code on a Forgejo instance but running CI through GitHub?

> With Woodpecker/Jenkins you know exactly what your pipeline is doing.

If you wrote it from the ground up, sure. On the other hand, I've inherited Jenkins pipelines that were written years before I got there and involved three to four different plugins, and they're way worse to work with than the GitHub Actions that I inherited.

Re: I'll think twice before using GitHub Actions again

#83
> Our code sits in a monorepo which is further divided into folders. Every folder is independent of each other and can be tested, built, and deployed separately.

If this is true, and you still have problems running specific Actions, why not break this into separate repositories?

Re: I'll think twice before using GitHub Actions again

#84

Earlier quoted context omitted.

At this point, just pause with Github Actions and compare it to how GiLab handles CI. Much more intuitive, taking shell scripts and other script commands natively and not devolving into a mess of obfuscated typescript wrapped actions that need a shit ton of dependencies.

But you can do the same with GitHub, right? Although most docs and articles focus on 3rd party actions, nothing stops you to just run everything in your own shell script.

Yes, you can, and we do at my current job. Much of the time it's not even really the harder approach compared to using someone else's action, it's just that the existence of third party actions makes people feel obliged to use them because they wouldn't want to be accused of Not Invented Here Syndrome.

Re: I'll think twice before using GitHub Actions again

#85
post #27

Earlier quoted context omitted.

I don't understand why this is not the evident approach for everyone writing GitHub Actions/GitLab CI/CD yaml etc.... I've struggled in some teams to explained why it's better to extract your command in scripts (ShellCheck on it, scripts are simple to run locally etc...) instead of writing a Frankenstein of YAML and shell commands. I hope someday to find an authoritative guidelines on writing pipeline that promote th…

My "favorite" is when I see people go all in, writing thousands of lines of Jenkins-flavor Groovy that parses JSON build specifications of arbitrary complexity to sort out how to build that particular project. "But then we can reuse the same pipeline for all our projects!"

I can rarely reuse the same pipeline for the same project 6 months down the road, much less reuse for anything else.

The few bits that end up getting reused are the externalized bash scripts.

Re: I'll think twice before using GitHub Actions again

#86
post #70
post #27

Earlier quoted context omitted.

I don't understand why this is not the evident approach for everyone writing GitHub Actions/GitLab CI/CD yaml etc.... I've struggled in some teams to explained why it's better to extract your command in scripts (ShellCheck on it, scripts are simple to run locally etc...) instead of writing a Frankenstein of YAML and shell commands. I hope someday to find an authoritative guidelines on writing pipeline that promote th…

it can be quite hard to write proper scripts that work consistently... different shells have different behaviours, availability of local tools, paths, etc and it feels like fighting against the flow when you're trying to make it reusable across many repos

Containerize the build environment so everything is captured (dependencies, build tools, etc)

Re: I'll think twice before using GitHub Actions again

#88

I tried to use GitHub Actions on Forgejo and... It's so much worse than using an actual CI pipeline. With Woodpecker/Jenkins you know exactly what your pipeline is doing. With GitHub actions, not even the developers of the actions themselves know what the runner does.

Best one I've used is the CI of sourcehut. So simple and so damn easy to set up.

Re: I'll think twice before using GitHub Actions again

#89

Oh boy, there's a special kind of hell I enter into everytime I set up new github actions. I wrote a blog post a few months ago about my pain[0] but one of the main things I've found over the years is you can massively reduce how horrible writing github actions is by avoiding prebuilt actions, and just using it as a handy shell runner. If you write behaviour in python/ruby/bash/hell-rust-if-you-really-want and leave…

At this point, just pause with Github Actions and compare it to how GiLab handles CI. Much more intuitive, taking shell scripts and other script commands natively and not devolving into a mess of obfuscated typescript wrapped actions that need a shit ton of dependencies.

The problem with Gitlab CI is that now you need to use Gitlab.

I’m not even sure when I started feeling like that was a bad thing. Probably when they started glueing a bunch of badly executed security crud onto the main product.

Re: I'll think twice before using GitHub Actions again

#90
post #86
post #70

Earlier quoted context omitted.

it can be quite hard to write proper scripts that work consistently... different shells have different behaviours, availability of local tools, paths, etc and it feels like fighting against the flow when you're trying to make it reusable across many repos

Containerize the build environment so everything is captured (dependencies, build tools, etc)

If you're not containerizing your CI/CD, you're really lost.
Post reply on HN