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

361–370 of 584 posts

Re: The Pain That Is GitHub Actions

#361

Post by folmar »

forrestthewoods wrote: post #119
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…

> pipelines can run locally on a developer machine as well (as much as possible at least) Facts. However I’ll go a step further and say “only implement your logic in a tool that has a debugger”. YAML is the worse. But shell scripts are second worst. Use a real language.

There is a debugger for bash: https://github.com/Trepan-Debuggers/bashdb Not that I'm recommending 10k-line programs in bash, but a debugger is useful when you need it.

Re: The Pain That Is GitHub Actions

#362

Post by folmar »

dathinab wrote: post #286
tasuki wrote: post #213

Earlier quoted context omitted.

> 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

I see the slow cache problem as universal. On a single-machine gitlab runner instance the upload to _local_ cache seems to take ages, double digit number of seconds for 100 MB archive.

Re: The Pain That Is GitHub Actions

#363

Post by kevincox »

gazereth wrote: post #124
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…

Pinning dependencies is trading one problem for another. Yes, your builds will work as expected for a stretch of time, but that period will come to an end, eventually. Then one day you will be forced to update those pinned dependencies and you might find yourself having to upgrade through several major versions, with breaking changes and knock-on effects to the rest of your pipelines. Allowing rolling updates to depe…

That isn't even the biggest problem. That breaks, and breakage gets fixed. Other than some slight internal delays there is little harm done. (You have a backup emergency deploy process that doesn't depend on GitHub anyways right?)

The real problem is security vulnerabilities in these pinned dependencies. You end up making a choice between:

1. Pin and risk a malicious update.

2. Don't pin and have your dependencies get out of date and grow known security vulnerabilities.

Re: The Pain That Is GitHub Actions

#364

Post by 12_throw_away »

sepositus wrote: post #9

Also an Earthly casualty here. Now having to look at Dagger.

There is at a tiny glimmer of life on the earthly front - yesterday, they merged their first changes in 6 months:

[1] https://github.com/earthly/earthly/commit/6d7f6786ad9fa4392f... [2] https://github.com/earthly/earthly/commit/89d31fc014a8980a50...

I am really really hoping that someone (not me, I've already tried and failed) could slim it down into a single-purpose, self-contained, community maintainable tool ...

Re: The Pain That Is GitHub Actions

#365

Post by quesera »

anttiharju wrote: post #331
quesera wrote: post #313

Earlier quoted context omitted.

I believe this is a good use for a GitHub machine account. IIRC, GitHub recommends this practice in their docs, with a username of "YOUR_USERNAME-machine". The machine user is just an ordinary GitHub user, added as a member of the organization, with all the necessary repo permissions, and a generated access token added to the GH repo Secrets. The organization owner then manages this GH machine account as well as the…

Using machine/service accounts across an org can (relatively) easily hit rate limits, better way is to use a github app instead for generating the tokens: https://github.com/peter-evans/create-pull-request/blob/main...

Good to know, thanks.

We have not hit any rate limiting so far, but we're a relatively small team -- a dozen devs, a few hundred commits per day that trigger CI (we don't do CD), across half a dozen active repos.

Re: The Pain That Is GitHub Actions

#366

Post by shykes »

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…

> Sad to see Earthly halting development and Dagger jumping on the AI train :(. Hopefully we'll get a proper alternative.

Hi, Dagger CEO here. We're advertising a new use case for Dagger (running AI agents) while continuing to support the original use case (running complex builds and tests). Dagger has always been a general purpose engine, and our community has always used it for more than just CI. It's still the exact same engine, CLI, SDKs and observability stack. It's not like we're discontinuing a product, to the contrary: we're getting more workloads on the platform, which benefits all our users.

Re: The Pain That Is GitHub Actions

#367

Post by arcanemachiner »

internetter wrote: post #353
deng wrote: post #190

Earlier quoted context omitted.

Dagger is even YCombinator funded. https://www.boringbusinessnerd.com/startups/dagger Mise indeed isn't, but its scope is quite a bit smaller than Dagger.

> Mise indeed isn't, but its scope is quite a bit smaller than Dagger. A lot of us could learn... do one thing and do it well

Ironic, because mise is a glued-together combination of asdf, direnv, and Makefiles.

Re: The Pain That Is GitHub Actions

#368

Post by claytonjy »

speleding wrote: post #185
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 would like to add one point: * Consider whether it's not easier to do away with CI in the cloud and just build locally on the dev's laptop With fast laptops and Docker you can get perfectly reproducible builds and tests locally that are infinitely easier to debug. It works for us.

How do you ensure what a dev builds and tags and pushes is coherent, meaning the tag matches the code commit it’s expected to?

I think builds must be possible locally, but i’d never rely on devs for the source of truth artifacts running in production, past a super early startup.

Re: The Pain That Is GitHub Actions

#369

Post by colemannerd »

shykes wrote: post #360
jimmcslim wrote: post #251

Earlier quoted context omitted.

In addition to the other comments suggesting dagger is not the saviour due to being VC-funded, it seems like they have decided there's no money in CI, but AI... yes there's money there! And "something something agents". From dagger.io... "The open platform for agentic software. Build powerful, controllable agents on an open ecosystem. Deploy agentic applications with complete visibility and cross-language capabilitie…

Hello! Dagger CEO here. Yes, we discovered that, in addition to running CI pipelines, Dagger can run AI agents. We learned this because our own users have told us. So now we are trying to capitalize on it, hence the ongoing changes to our website. We are trying to avoid the "something something agents" effect, but clearly, we still have work to do there :) It's hard to explain in marketing terms why a ephemeral execu…

Please be careful. I'd love to adopt Dagger, but the UI in comparison to GHA, is just not a value add. I'd hate for y'all to go the AI route that Arc did... and lose all your users. There is A LOT to CICD, which can be profitable. I think there's still a lot more features needed before it's compelling and I would worry Agentic AI will lead you to a hyper-configurable, muddled message.

Re: The Pain That Is GitHub Actions

#370

Post by solatic »

> Trivial mistakes (formatting, unused deps, lint issues) should be fixed automatically, not cause failures.

Do people really consider this best practice? I disagree. I absolutely don't want CI touching my code. I don't want to have to remember to rebase on top of whatever CI may or may not have done to my code. Not all linters are auto-fixable so anyway some of the time I would need to fix it from my laptop. If it's a trivial check it should run as a pre-commit hook anyway. What's next, CI should run an LLM to auto-fix failing test cases?

Do people actually prefer CI auto-fixing anything?

Post reply on HN