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

261–270 of 584 posts

Re: The Pain That Is GitHub Actions

#261

Post by carderne »

kelseydh wrote: post #121
carderne wrote: post #104

Earlier quoted context omitted.

Your prod deployment should require access to some secrets that are only available to workflows running against main.

I'm interested in learning more about this. How would we go about adding a secret only available to runners on the main branch? Is there a configuration option on Github to create a secret only available to runners on main? Presumably anything configured via a .github workflow wouldn't assure safety, as those files can be edited to trigger unexpected actions like deploys on working branches. Our Github Action workflo…

The docs here [0] do a decent job explaining it.

You create an environment, restrict it to the main branch, add your secret to it and then tie your deploy workflow to it.

If someone runs that workflow against another branch it will run but it won’t be able to access those secrets.

[0] https://docs.github.com/en/actions/managing-workflow-runs-an...

Re: The Pain That Is GitHub Actions

#262

Post by ManBeardPc »

z3t4 wrote: post #255
ManBeardPc wrote: post #177

CI environments like Gitlab or Github are my nemesis. Another technology that everyone swears is absolute necessary but somehow makes everything more complicated. The provided environments in companies so far are hell 100% the time and managed by inexperienced personnel with zero or little programming experience. * Barely reproducible because things like the settings of the server (environment variables are just one…

It's such a waste of resources to rebuild an operating system every time you want to run some tests, and these CI machines are much less powerful then personal computers so it takes much longer in the cloud too. If you have your CI in your own scripts it will be easy to migrate between CI environments too. build: ./buuild.sh test: ./test.sh deploy: ./deploy.sh maybe pass some env variables to the scripts. There are s…

The resource usage is really a big problem (if you don't sell them). Being stateless is a blessing and curse at the same time. Reproducible but forces you to feed in all required data every time.

Simple scripts like these are enough for most projects and it is a blessing if you can execute them locally. Having a CI platform doing it automatically on push/merge/schedule is still possible and makes migrations to other platforms easier.

Re: The Pain That Is GitHub Actions

#263

Post by IshKebab »

dkdbejwi383 wrote: post #214
ironmagma wrote: post #178

Earlier quoted context omitted.

The non-solution solution, to simply downplay the issues instead of fixing them. You can solve almost anything this way, but also isn't it nice when things around you aren't universally slightly broken?

I guess I'd disagree that this is "slightly broken". That's just how it works. I don't think there's some universally perfect solution that magically just works all the time and never needs intervention or updating.

> That's just how it works.

It's how it works now. It doesn't have to forever. We can imagine a future in which it works in a better way. One that isn't so annoying.

> I don't think there's some universally perfect solution that magically just works all the time and never needs intervention or updating.

Again you seem to be confused as to what the issue is. Maintenance is not painful. Initial development is.

Re: The Pain That Is GitHub Actions

#264

Post by kbolino »

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...

When it gets realistic, with conditions, variable substitutions, etc., it ends up being 20 steps in a language that isn't shell but is calling shell over and over again, and can't be run outside of CI. Whereas, if you just wrote one shell script, it could've done all of those things in one language and been runnable locally too.

Re: The Pain That Is GitHub Actions

#266

Post by hv42 »

xlii wrote: post #103

There is one thing that I haven’t seen mentioned: worst possible feedback loop. I’ve noticed this phenomenon few times already, and I think there’s nothing worse than having a 30-60s feedback loop. The one that keeps you glued to the screen but otherwise is completely nonproductive. I tried for many moons to replicate GHA environment on local and it’s impossible in my context. So every change is like „push, wait for…

With GitLab, I have found https://github.com/firecow/gitlab-ci-local to be an incredible time-saver when working with GitLab pipelines (similar to https://github.com/nektos/act for GitHub)

I wish GitLab/GitHub would provide a way to do this by default, though.

Re: The Pain That Is GitHub Actions

#267

Post by axelfontaine »

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?

At https://sprinters.sh we offer AWS-hosted runners at a price point that will be much more suitable for a company like yours.

Re: The Pain That Is GitHub Actions

#268

Post by pimeys »

jalaziz wrote: post #53

GitHub Actions started off great as they were quickly iterating, but it very much seems that GitHub has taken its eye of the ball and the improvements have all but halted. It's really upsetting how little attention Actions is getting these days ( https://github.com/orgs/community/discussions/categories/act... > tells the story -- the most popular issues have gone completely unanswered). Sad to see Earthly halting dev…

We switched to Depot last week. Our Rust builds went down from 20+ minutes to 4-8 minutes. The easy setup and their docker builds with fast caching are really good.

Re: The Pain That Is GitHub Actions

#269

Post by pepoluan »

motorest wrote: post #242
jillesvangurp wrote: post #105

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. If it gets complicated, dumb it down to "run this script". Scripts are a lot easier to write and debug than thousands of lines of yaml doing god knows what. The problem isn't github actions but people overloading their build and CI system wit…

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

People hates YAML because doing so makes them look cool and trendy. Just like Python-hating. Even if their 'hate' is misdirected.

I'm an experienced SaltStack user. If I found something I need is too complex to be described in YAML, I'll just write a custom module and/or state. Use YAML just to inform Salt what should happen, and shove the logic in the Python files.

People really should become generalists if they handle the plumbing.

Re: The Pain That Is GitHub Actions

#270

Post by DanielHB »

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…

Man I tried this approach by making my builds dockerized, turns out docker layer caching is pretty slow on CI and adds a lot of overhead locally.

Do not recommend this approach (of using docker for building).

Post reply on HN