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

471–480 of 584 posts

Re: The Pain That Is GitHub Actions

#471

Post by sleepybrett »

cookiengineer wrote: post #134
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. I heavily invested in a local runner based CI/CD workflow. First I was using gogs and drone, now the forgejo and woodpecker CI forks. It runs with multiple redundancies because it's a pretty easy setup to replicate on decentralized hardware. The only thing that's a little painful is authentication and cross-system pull requests, so we still need our single point of failure to merge feature branches and do code…

Did they finally actually say how the tj actions repo got compromised. When I was fixing that shit on saturday it was still 'we don't know how they got access!?!?'

Re: The Pain That Is GitHub Actions

#472

Post by stasge »

While I agree that GitHub Actions could be more "secure and safe" by default most gaps are easy enough to fill. With https://github.com/marketplace/actions/check-actions you can ensure timeouts, permissions and version pinning. With https://registry.terraform.io/modules/giner/repo/github you can manage all repos together with workflows.

Re: The Pain That Is GitHub Actions

#473

Post by shykes »

jalaziz wrote: post #439
shykes wrote: post #366

Earlier quoted context omitted.

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

Great to know. I think the fear is that so many companies are prioritizing AI workloads for the valuation bump rather than delivering actual meaningful value.

I completely understand that fear. I see lots of other tech companies making that mistake, throwing away a perfectly good product and market out of pure "FOMO". I really, really don't want us to be one of those companies.

I think what we're doing is different: we built a product that was always meant to be general purpose; encouraged our community to experiment with alternative use cases; and are now doubling down on a new use case, for the same product. We are still worried about the perception of a FOMO-driven AI pivot (and the reactions on this thread confirm that we still have work to do there); but we're confident that the product really is capable of supporting both.

Thank you for the thoughtful comments, I appreciate it.

Re: The Pain That Is GitHub Actions

#474

Post by shykes »

nand_gate wrote: post #454
shykes wrote: post #416

Earlier quoted context omitted.

Dagger.io does this out of the box: - Everything sandboxed in containers (works the same locally and in CI) - Integrate your build tools by executing them in containers - Send traces, metrics and logs for everything at full resolution, in the OTEL format. Visualize in our proprietary web UI, or in your favorite observability tool

It's doa, Sol.

Since you're using my first name in a weird and creepy way, I'll assume you're a hater. It's been so long since I've had one! Are you reactivating from the Docker days, or are you the first of a new cohort? That would be an exciting development, since getting haters is a leading sign of runaway success.

Re: The Pain That Is GitHub Actions

#475

Post by jimbokun »

mikepurvis wrote: post #398
steeleduncan wrote: post #392

Earlier quoted context omitted.

> Write as much CI logic as possible in your own code Nix really helps with this. Its not just that you do everything via a single script invocation, local or ci, you do it in an identical environment, local or ci. You are not trying to debug the difference between Ubuntu as setup in GHA or Arch as it is on your laptop. Setting up a nix build cache also means that any artefact built by your CI is instantly available…

Absolutely. Being able to have a single `nix build` line that gets all the way from source to your final asset (iso, ova, container image, whatever) with everything being aggressively cached all the way along is a game changer. I think it's worth the activation energy for a lot more organizations than realize it.

Sounds like a business that surfaces the power of Nix with a gentle learning curve as a simpler, cleaner CI tool could have some success. Every time I see Nix come up, it’s described as very powerful but difficult to learn to use.

Re: The Pain That Is GitHub Actions

#476

Post by jimbokun »

noplacelikehome wrote: post #442
hi_hi wrote: post #234

Earlier quoted context omitted.

I came to the exact same conclusion accidentally in my first role as a Tech Lead a few years back. It was a large enterprise CMS project. The client had previously told everyone they couldn't automate deployments due to the hosted platform security, so deployments of code and configs were all done manually by a specific support engineer following a complex multistep run sheet. That was going about as well as you'd ex…

Nix is awesome for this -- write your entire series of CI tools in she'll or Python and run them locally in the exact same environment as they will run in CI. Add SOPS to bring secrets along for the ride.

Would Nix work well with GitHub Actions? Or is it more of a replacement? How do you automate running tests and deploying to dev on every push, for example?

Re: The Pain That Is GitHub Actions

#477

Post by jimbokun »

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 feel like more time is spent getting CI working these days than on the actual applications.

Between that and upgrading for security patches. Developing user impacting code is becoming a smaller and smaller part of software development.

Re: The Pain That Is GitHub Actions

#478

Post by jimbokun »

jimmcslim wrote: post #251
oulipo wrote: post #143

Earlier quoted context omitted.

mise ( https://mise.jdx.dev/ ) and dagger ( https://github.com/dagger/dagger ) seem like nice candidates too! Mise can install all your deps, and run tasks

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…

Take out each reference to AI and the meaning doesn’t change in the slightest.

Re: The Pain That Is GitHub Actions

#479

Post by ch4s3 »

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

The caching is atrocious and seems to not correctly restore our cache randomly in parallel jobs in the same run. It’s the worst CI that I’ve ever used.

Re: The Pain That Is GitHub Actions

#480

Post by kelseydh »

carderne wrote: post #261
kelseydh wrote: post #121

Earlier quoted context omitted.

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

Thank you, very helpful!
Post reply on HN