Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'll think twice before using GitHub Actions again

ninkovic.dev

Post reply on HN
Print view View original

191–200 of 284 posts

Re: I'll think twice before using GitHub Actions again

#191

Post by cjk »

I have never used a CI system more flaky and slow than GitHub Actions. The one and only positive thing about it is that you get some Actions usage for free.

The Azure machines GitHub uses for the runners by default have terrible performance in almost every regard (network, disk, CPU). Presumably it would be more reliable when using your own runners, but even the Actions control plane is flaky and doesn't always schedule jobs correctly.

We switched to Buildkite at $DAYJOB and haven't looked back.

Re: I'll think twice before using GitHub Actions again

#192

Post by cjk »

ripped_britches wrote: post #147

My man/woman - you gotta try buildkite. It’s a bit more extra setup since you have to interface with another company, more API keys, etc. But when you outgrow GH actions, this is the way. Have used buildkite in my last two jobs (big US tech companies) and it has been the only pleasant part of CI.

This is indeed the way.

Re: I'll think twice before using GitHub Actions again

#193

Post by saghm »

arghwhat wrote: post #5

> no way of running actions locally My policy is to never let pipeline DSLs contain any actual logic outside orchestration for the task, relying solely on one-liner build or test commands. If the task is more complicated than a one-liner, make a script for it in the repo to make it a one-liner. Doesn't matter if it's GitHub Actions, Jenkins, Azure DevOps (which has super cursed yaml), etc. This in turn means that you…

This is my preferred way of doing things as well. Not being able to run the exact same thing that's running in CI easily locally is a bit of a red flag in my opinion. I think the only exception I've ever encountered to this is when working on client software for HSMs, which had some end-to-end tests that couldn't be run without actually connecting to the specific hardware that took some setup to be able to access when running tests locally.

Re: I'll think twice before using GitHub Actions again

#194

Post by chubot »

nunez wrote: post #55

Posts like this make me miss Travis. Travis CI was incredible, especially for testing CI locally. (I agree with the author that act is a well done hack. I've stopped using it because of how often I'd have something pass in act and fail in GHA.) > GitHub doesn't care My take: GitHub only built Actions to compete against GitLab CI, as built-in CI was taking large chunks of market share from them in the enterprise.

How so? I don’t recall this, and I used Travis, and then migrated to GitHub actions.

As far as I can tell, they are identical as far as testing locally. If you want to test locally, then put as much logic in shell scripts as possible, decoupled from the CI.

Re: I'll think twice before using GitHub Actions again

#195

Post by kjuulh »

electromech wrote: post #98
kjuulh wrote: post #25

I am biased because I built the rust SDK for dagger. But I think it is a real step forward for CI. Is it perfect? Nope. But it allows fixing a lot of the shortcomings the author has. Pros: - pipeline as code, write it as golang, python, typescript or a mix of thr above. - Really fast once cached - Use your languages library for code sharing, versioning and testing - Runs everywhere local, ci etc. Easy to change from…

I'm genuinely intrigued by Dagger, but also super confused. For example, this feels like extra complexity around a simple shell command, and I'm trying to grok why the complexity is worth it: https://docs.dagger.io/quickstart/test/#inspect-the-dagger-f... I'm a fanboy of Rust, Containerization, and everything-as-code, so on paper Dagger and your Rust SDK seems like it's made for me. But when I read the examples... I…

It is a perfectly valid crtitisim dagger is not a full build system that dictates what your artifacts look like. Unlike maybe something like bazel or nix. I think of dagger as a sort of interface that now allows me to test and package my build and ci into smaller logical bits and rely on the community for parts of it as well.

In the end you do end up slinging apt install commands for example, but you can test those parts in isolation. Does my ci actually scan this kind of vulnerability, install postgres driver, when I build a rust binary is it musl and working on scratch images.

In some sense dagger feels a little but like a programmatic wrapper on top of docker, because that is actually quite close to what it is.

You can also use it for other things because in my mind it is the easiest way of orchestrating containers. For example running renovate over a list of repositories, spawning adhoc llm containers (pre ollama), etc. Lots of nice uses outside of ci as well even if it is the major selling point

Re: I'll think twice before using GitHub Actions again

#196

Post by tsimionescu »

akoboldfrying wrote: post #159
carlmr wrote: post #90

Earlier quoted context omitted.

If you're not containerizing your CI/CD, you're really lost.

That might be the case if Docker did in fact guarantee (or at least make it easy to guarantee) deterministic builds -- but it doesn't really even try: 1. Image tags ("latest", etc.) can change over time. Does any layer in your Dockerfile -- including inside transitive deps -- build on an existing layer identified by tag? If so, you never had reproducibility. 2. Plenty of Dockerfiles include things like "apt-get some-…

The advantage that Docker brings isn't perfect guaranteed reusability, it's complete independence (or as close you can easily get while not wasting resources on VMs) from the system on which the build is running, plus some resuability in practice in a certain period of time, and given other good practices.

Sure, if I try to rebuild a docker image from 5 years ago, it may fail, or produce something different, because it was pulling in some packages that have changed significantly in apt, or perhaps pip has changed encryption and no longer accepts TLS1.1 or whatever. And if you use ':latest' or if your team has a habit of reusing build numbers or custom tags, you may break the assumptions even sooner.

But even so, especially if using always incremented build numbers as image tags, a docker image will work the same way om the Jenkins system, the GitHub Actions pipeline, and every coworker's local build, for a while.

Re: I'll think twice before using GitHub Actions again

#197

Post by kjuulh »

mdaniel wrote: post #117
electromech wrote: post #98

Earlier quoted context omitted.

I'm genuinely intrigued by Dagger, but also super confused. For example, this feels like extra complexity around a simple shell command, and I'm trying to grok why the complexity is worth it: https://docs.dagger.io/quickstart/test/#inspect-the-dagger-f... I'm a fanboy of Rust, Containerization, and everything-as-code, so on paper Dagger and your Rust SDK seems like it's made for me. But when I read the examples... I…

I'm merely an outsider to Dagger, but I believe the page you linked to would give one the impression "but why golang[1] around some shell literals?!" because to grok its value one must understand that m.BuildEnv(source) https://docs.dagger.io/quickstart/env#inspect-the-dagger-fun... > is programmatically doing what https://docs.github.com/en/actions/writing-workflows/workflo... would do: define the docker image (if a…

Exactly. When comparing dagger with a lot of the other formats for ci, it may seem more logical. Ive spent so much time debugging github actions, waiting 10 minutes for testing a full pipeline after a change etc. Over an over again. Dagger has a weird DSL in the programming languages as well but at least it is actual code that I can write for loops around or give parameters and reuse. The instead of a groovy file for Jenkins ;)

Re: I'll think twice before using GitHub Actions again

#199

Post by eru »

derkades wrote: post #198
eru wrote: post #177

Earlier quoted context omitted.

I bet all your targets are .PHONY?

But I can install it on any Linux system from the base repository

If all your targets are .PHONY, you might as well just as bash (or your favourite shell) directly.

Make targets look suspiciously like functions (or procedures), but they actually aren't.

Re: I'll think twice before using GitHub Actions again

#200

Post by lloeki »

arghwhat wrote: post #5

> no way of running actions locally My policy is to never let pipeline DSLs contain any actual logic outside orchestration for the task, relying solely on one-liner build or test commands. If the task is more complicated than a one-liner, make a script for it in the repo to make it a one-liner. Doesn't matter if it's GitHub Actions, Jenkins, Azure DevOps (which has super cursed yaml), etc. This in turn means that you…

I'm increasingly designing CI stuff around rake tasks. Then I run rake in the workflow.

But that caters only for each individual command... as you mention the orchestration is still coded in, and duplicated from what rake knows and would do.

So I'm currently trying stuff that has a pluggable output: one output (the default) is that it runs stuff, but with just a rake var, instead of generating then running commands it generates workflow content that ultimately gets merged in an ERB workflow template.

The model I like the most though is Nix-style distributed builds: it doesn't matter if you do `nix build foo#bar` (local) or `nix build -j0 foo#bar` (zero local jobs => use a remote builder†), the `foo#bar` "task" and its dependents gets "built" (a.k.a run).

† builders get picked matching target platform and label-like "features" constraints.

Ever since there has been gitlab-runner, I've wondered why the hell can't I just submit some job to a (list of) runner(s) - some of which could be local - without the whole push-to-repo+CI orchestrator? I mean I don't think it would be out of this world to write a CLI command that locally parses whatever-ci.yml, creates jobs out of it, and submit them to a local runner.

Post reply on HN