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

81–90 of 584 posts

Re: The Pain That Is GitHub Actions

#81

Post by tobinfekkes »

This is the joy of HN, for me, at least. I'm genuinely fascinated to read that both GitHub Actions and DevOps are (apparently) so universally hated. I've been using both for many years, with barely a hiccup, and I actually really enjoy and value what they do. It would never have dawned on me, outside this thread, to think that so many people dislike it. Nice to see a different perspective!

Are the Actions a little cumbersome to set up and test? Sure. Is it a little annoying to have to make somewhat-useless commits just to re-trigger an Action to see if it works? Absolutely. But once it works, I just set it and forget it. I've barely touched my workflows in ~4 years, outside of the Node version updates.

Otherwise, I'm very pleased with both. My needs must just be simple enough to not run into these more complicated issues, I guess?

Re: The Pain That Is GitHub Actions

#82

Post by HdS84 »

jicea wrote: post #33

Genuine question: what's the GitLab equivalent of GitHub Actions? I'm using GitHub Actions to easily reuse some predefined job setup (like installing a certain Python version on Linux, macOS, Windows runners). For these tyoe of tasks, I find GitHub actions very useful and convenient. If you want to reuse predefined jobs, written by someone else, with GitLab CI/CD, what can I use?

There is nothing. Oh sure there is include, but that's like most gitlab features: it marks a nice shiny checkbox in some management presentation. But usefulness in the real world is limited. But hey let's do secops oh no AI instead!

Re: The Pain That Is GitHub Actions

#83

Post by out-of-ideas »

usr1106 wrote: post #45
yoyohello13 wrote: post #28

Earlier quoted context omitted.

Glad I’m not the only one. GitLab runners just make sense to me. A container you run scripts in. I have some GitHub actions for some side projects and it just seems so much more confusing to setup for some reason.

So Github was really the perfect acquisation for the Microsoft portfolio. Applications with a big market share that are technically inferior to the competition. // Luckily still a gitlab user, but recently forced to Microsoft Teams and office.

> recently forced to Microsoft Teams

my condolences to you and your team for that switch; it's my 2nd used-and-disliked thing (right next to atlassian) - oh well

but one cool feature i found with ms teams that zoom did not have (some years ago - no clue now) is turning off incoming video so you dont have to be constantly distracted in meetings

edit: oh yeah, re github actions and the user that said: > Glad I’m not the only one

me too, me too; gh actions seem frustrating (from a user hardly using gh actions, and more gitlab things - even though gitlab seems pretty wonky at times, too)

Re: The Pain That Is GitHub Actions

#84

Post by pinkgolem »

mubou wrote: post #77
briansmith wrote: post #57

Earlier quoted context omitted.

Actions have special integration with GitHub (e.g. they can annotate the pull request review UI) using an API. If you forgo that integration, then you can absolutely use GitHub Actions like "a container you run scripts in." This is the advice that is usually given in every thread about GitHub Actions.

Devil's advocate: They could make the github CLI capable of doing all of those things (if it's not already), and then the only thing the container needs is a token.

There are multiple ways you can do this already from within a script

Re: The Pain That Is GitHub Actions

#86

Post by deng »

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 on a developer machine as well (as much as possible at least), otherwise testing/debugging pipelines becomes a nightmare.

* Avoid YAML as much as possible, period.

* Don't bind yourself to some fancy new VC-financed thing that will solve CI once and for all but needs to get monetized eventually (see: earthly, dagger, etc.)

* Always use your own runners, on-premise if possible

Re: The Pain That Is GitHub Actions

#87

Post by Aeolun »

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…

This is where I was going to say something about dagger, but it seems it turned into AI crud.

Let me at least recommend depot.dev for having absurdly fast runners.

Re: The Pain That Is GitHub Actions

#88

Post by alex_suzuki »

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…

> * Always use your own runners, on-premise if possible

Why? I understand it in cases where security is critical or intellectual property is at stake. Are you talking about "snowflake runners" or just dumb executors of container images?

Re: The Pain That Is GitHub Actions

#89

Post by Xiol32 »

yoyohello13 wrote: post #24

My team uses GitLab and most other teams are on Azure dev ops. They keep trying to get us to switch telling us how amazing pipelines are. Glad to know we are not missing anything.

Having recently been involved in a Gitlab to ADO migration, keep fighting the fight. It is such a step backwards.

Re: The Pain That Is GitHub Actions

#90

Post by [deleted] »

alex_suzuki wrote: post #88
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…

> * Always use your own runners, on-premise if possible Why? I understand it in cases where security is critical or intellectual property is at stake. Are you talking about "snowflake runners" or just dumb executors of container images?

[deleted]
Post reply on HN