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

301–310 of 584 posts

Re: The Pain That Is GitHub Actions

#301

Post by voxic11 »

dathinab wrote: post #106
tobinfekkes wrote: post #81

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 cu…

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…

> no need for compliance enforcement stuff

I find github actions works very well for compliance. The ability to create attestations makes it easy to enforce policies about artifact provenance and integrity and was much easier to get working properly compared to my experience attempting to get jenkins to produce attestations.

https://docs.github.com/en/actions/security-for-github-actio...

https://docs.github.com/en/actions/security-for-github-actio...

What was your issue with it?

Re: The Pain That Is GitHub Actions

#302

Post by kylegalbraith »

magicalhippo wrote: post #257
kylegalbraith wrote: post #55

This was an interesting read and highlighted some of the author's top-of-mind pain points and rough edges. However, in my experience, this is definitely not an exhaustive list, and there are actually many, many, many more. Things like 10 GB cache limits in GitHub, concurrency limits based on runner type, the expensive price tag for larger GitHub runners, and that's before you even get to the security ones. Having bee…

Depot looks nice, but also looks fairly expensive to me. We're a small B2B company, just 10 devs, but we'd be looking at 200+500 = $700/mo just for building and CI. I guess that would be reasonable if we really needed the speedup, but if you're also offering a better QoL GHA experience then perhaps another tier for people like us who don't necessarily need the blazing speed?

We're rolling out new pricing in the next week or two that should likely cover your use case. Feel free to ping me directly, email in my bio, if you'd like to learn more.

Re: The Pain That Is GitHub Actions

#304

Post by kylegalbraith »

joshstrange wrote: post #243

> Why do I need a custom token? Because without it, the release completes, but doesn't trigger our post-release workflow. This is so frustrating. Having to inject a PAT into the workflow just so it will kick off another workflow is not only annoying but it just feels wrong. Also not lots of operations are tied to my user which I don't like. > It doesn't help that you can't really try any of this locally (I know of [a…

Just flagging that Depot now has macOS and Windows runners [0] as well if you're looking for even faster builds. I also recognize that constantly reevaluating runners isn't on everyone's priority list.

[0] https://depot.dev/docs/github-actions/runner-types

Re: The Pain That Is GitHub Actions

#305

Post by withinboredom »

zoobab wrote: post #200
deng wrote: post #93

Earlier quoted context omitted.

It obviously depends on your load. Fast pipelines matter, so don't run them on some weak cloud runner with the speed of a C64. Fast cloud runners are expensive. Just invest some money and buy or at least rent some beefy servers with lots of cores, RAM and storage and never look back. Use caches for everything to speed up things. Security is another thing where this can come in handy, but properly firewalling CI runne…

"Fast cloud runners are expensive." Buy a cheap Ryzen, and put it on your desk, that's a cheap runner.

30 bucks a month on hetzner for a dedicated machine with 12-16 cores and 64 gb of ram and unlimited 1gbps bandwidth.

Re: The Pain That Is GitHub Actions

#306

Post by tom_ »

motorest wrote: post #250
cmsj wrote: post #247

Earlier quoted context omitted.

So, I'm not interested in the debate about the correctness (or otherwise) of yaml as a declarative programming language, but I will say this... iterating a GitHub Actions workflow is a gigantic pain in the ass. Capturing all of the important logic in a script/makefile/whatever means I can iterate it locally way faster and then all I need github to do is provision an environment and call my scripts in the order I requ…

> iterating a GitHub Actions workflow is a gigantic pain in the ass. Capturing all of the important logic in a script/makefile/whatever means I can iterate it locally way faster and then all I need github to do is provision an environment and call my scripts in the order I require. What's wrong with this? https://docs.github.com/en/actions/writing-workflows/choosin...

Nothing significant on the face of it and I think that's pretty much exactly what's being suggested: don't have anything particularly interesting in the .yml file, just the bare minimum plus some small number of uncomplicated script invocations to install dependencies and actually do the build.

(Iterating even on this stuff by waiting for the runner is still annoying though. You need to commit to the repo, push, and wait. Hence the suggestion of having scripts that you can also run locally, so you can test changes locally when you're iterating on them. This isn't any kind of guarantee, but it's far less annoying to do (say) 15 iterations locally followed by the inevitable extra 3 remotely than it is having to do all 18 remotely, waiting for the runner each time then debugging it by staring at the output logs. Even assuming you'd be able to get away with as few as 15 given that you don't have proper access to the machine.)

Re: The Pain That Is GitHub Actions

#307

Post by withinboredom »

marcusramberg wrote: post #199
fergie wrote: post #131

Earlier quoted context omitted.

As a developer based in Norway, one fairly major drawback to YAML is the way that it processes the language code for Norwegian ("no").

That particular pain was fixed in yaml 1.2 :)

TIL I learned that yaml has versions and now I'm wondering what version of yaml parsers are running where. I think I might be on a new level of hell.

It would be better to delete your comment so nobody else has to has to ever have this crisis.

Re: The Pain That Is GitHub Actions

#309

Post by verdverm »

zamalek wrote: post #281
doix wrote: post #187

Earlier quoted context omitted.

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.

We're doing the same, but replacing the bash script with Dagger.

Once you get on Dagger, you can turn your CI into minimal Dagger invocations and write the logic in the language of your choice. Runs the same locally and in automation

Re: The Pain That Is GitHub Actions

#310

Post by enriquto »

terminalbraid wrote: post #215
ahub wrote: post #195

I don't see sourcehut [0] mentionned here. I tested github and gitlab CI, sourcehut is MILES ahead. I'll drop two key features here : - any CI run successful or not, gives you back a ssh URI so you can log into the machine to inspect/tweak/tinker - CI files are NOT in the project's repository. no need to wrangle with your git branches when working on CI anymore [0] : https://man.sr.ht/builds.sr.ht/

> CI files are NOT in the project's repository I don't use sourcehut, but interpreting what you wrote I'd argue this is an antifeature and would be a dealbreaker for me. CI typically evolves with the underlying code and decoupling that from the code makes it difficult to go backwards. It loses cohesion.

you can put them in the same repository, if that is your thing.

If you put the build files in a .builds/ folder at the root of your repository, they will be run upon each commit. Just like in github or gitlab. You are just not forced into this way of life.

If you prefer, you can store the build files separately, and run them independently of your commits. Moreover, the build files don't need to be associated to any repository, inside or outside sourcehut.

Post reply on HN