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

281–290 of 584 posts

Re: The Pain That Is GitHub Actions

#281

Post by zamalek »

doix wrote: post #187
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…

I came from the semiconductor industry, where everything was locally hosted Jenkins + bash scripts. The Jenkins job would just launch the bash script that was stored in perforce(vcs), so all you had to do to run things locally was run the same bash script. When I joined my first web SaaS startup I had a bit of a culture shock. Everything was running on 3rd party services with their own proprietary config/language/etc…

> I'm not convinced it's any better.

Your Jenkins experience is more valuable and worth replicating when you get the opportunity.

Re: The Pain That Is GitHub Actions

#282

Post by ozim »

motorest wrote: post #237
ozim wrote: post #126

Earlier quoted context omitted.

I don’t think it is insanity quite the opposite - insanity is trying to force everything in yaml or pipeline. I have seen people doing absolutely insane setups because they thought they have to do it in yaml and pipeline and there is absolutely no other option or it is somehow wrong to drop some stuff to code.

> I don’t think it is insanity quite the opposite - insanity is trying to force everything in yaml or pipeline. I'm not sure I understood what you're saying because it sounds too absurd to be real. The whole point of a CICD pipeline is that it automates all aspects of your CICD needs. All mainstream CICD systems support this as their happy path. You specify build stages and build jobs, you manage your build artifacts…

In the article Strange Way to Enforce Status Checks with Merge Queue.

All aspects of your CICD pipeline - rebasing PRs is not 'basic CICD' need.

CICD pipeline should take a commit state and produce artifacts from that state, not lint and not autofix trivial issues.

Everything that is not "take code state - run tests - build - deploy (eventualy fail)" is insanity.

Autofixing/linting for example should be separate process waay before CICD starts. And people do stuff like that because they think it is part of integration and testing. Trying to shove it inside is insanity.

Re: The Pain That Is GitHub Actions

#283

Post by zamalek »

silisili wrote: post #16

I worked at companies using Gitlab for a decade, and got familiar with runners. Recently switched to a company using Github, and assumed I'd be blown away by their offering because of their size. Well, I was, but not in the way I'd hoped. They're absolutely awful in comparison, and I'm beyond confused how it got to that state. If I were running a company and had to choose between the two, I'd pick Gitlab every time j…

> I'm beyond confused how it got to that state.

A few years back I wanted to throw in the towel and write a more minimal GHA-compatible agent. I couldn't even find where in the code they were calling out to GitHub APIs (one goal was to have that first party progress UI experience). I don't know where I heard this, so big hearsay warning, but apparently nobody at GitHub can figure it out either.

Re: The Pain That Is GitHub Actions

#284

Post by adminm »

I try to use as little of GHA specific things as possible. Use it as a runner but don't lock yourself into the platform. I want to be able to develop and run the CI outside GHA thank you very much.

Re: The Pain That Is GitHub Actions

#285

Post by cantagi »

elAhmo wrote: post #152
kelseydh wrote: post #135

Earlier quoted context omitted.

Feel this pain so much. If you are debugging Github Action container builds, and each takes over ~40 minutes to build.. you can burn through a whole work day only testing six or seven changes. There has to be a better way. How has nobody figured this out?

There is act, that allows you to run actions locally. Although not exactly the same as the real thing, it can save time. https://github.com/nektos/act

act is brilliant - it really helps iterate on github or gitea actions locally.

Re: The Pain That Is GitHub Actions

#286

Post by dathinab »

tasuki wrote: post #213
dathinab wrote: post #106

Earlier quoted context omitted.

It really depends on what you do? GitHub CI is designed in a way which tends to work well for - languages with no or very very cheap "compilation" steps (i.e. basically only scripting languages) - relatively well contained project (e.g. one JS library, no mono repo stuff) - no complex needs for integration tests - no need for compliance enforcement stuff, especially not if it has to actually be securely enforced inst…

> languages with no or very very cheap "compilation" steps (i.e. basically only scripting languages) This is not true at all. It's fine with Haskell, just cache the dependencies to speed up the build...

except that

- GitHub Action cache and build artifact handling is a complete shit show (slow upload, slow download and a lot of practical subtle annoyances, finished off with sub-par integration in existing build systems)

- GitHub runners are comparatively small, so e.g. larger linker steps can already lead to pretty bad performance penalties

and sure like I said, if you project is small it doesn't matter

Re: The Pain That Is GitHub Actions

#287

Post by ed_elliott_asc »

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…

* print out the working directory and a directory listing every time

Re: The Pain That Is GitHub Actions

#288

Post by hn_throwaway_99 »

dijit wrote: post #97
hn_throwaway_99 wrote: post #19

> A few days ago, someone compromised a popular GitHub Action. The response? "Just pin your dependencies to a hash." Except as comments also pointed out, almost no one does. I used GitHub actions when building a fin services app, so I absolutely used the hash to specify Action dependencies. I agree that this should be the default, or even the required, way to pull in Action dependencies, but saying "almost no one doe…

I think the HN community at large had a bit of a learning experience a couple of days ago. "Defaults matter" is a common phrase, but equally true is: "the pattern everyone recommends including example documentation matters". It is fair to criticise the usage of GH Actions, just like it's fair to criticise common usage patterns of MySQL that eat your data - even if smarter individuals (who learn from deep understandin…

I wholeheartedly agree, and perhaps it was just how I was interpreting the author's statement in the article. If it's saying that the "default" way of using GitHub Actions is dangerous and leads to subtle security footguns, I completely agree. But if you know the proper way to use and secure Actions, saying "everyone else does it a bad way" is irrelevant to your security posture.

Re: The Pain That Is GitHub Actions

#289

Post by otikik »

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…

> * Avoid YAML as much as possible, period.

That's also a very valid takeaway for life in general

Re: The Pain That Is GitHub Actions

#290

Post by robertlagrant »

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.

Azure DevOps seems extremely basic (and flaky!) compared to GitLab. My impression is from a couple of years ago though; perhaps it's amazing now.
Post reply on HN