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

I hate GitHub Actions with passion

xlii.space

Post reply on HN
Print view View original

271–280 of 347 posts

Re: I hate GitHub Actions with passion

#271

Post by ezekiel68 »

iguessthislldo wrote: post #227
woodruffw wrote: post #89

I think this post accurately isolates the single main issue with GitHub Actions, i.e. the lack of a tight feedback loop. Pushing and waiting for completion on what's often a very simple failure mode is frustrating. Others have pointed out that there are architectural steps you can take to minimize this pain, like keeping all CI operations isolated within scripts that can be run locally (and treating GitHub Actions fe…

I've never used gh workflow run, but I have used the GitHub API to run workflows and wanted to show the URL. I had to have it make another call to get the workflow runs and assume the last run is the one with the correct URL. This would obviously not work correctly if there were multiple run requests at the same time. Maybe some more checking could detect that, but it works for my purposes so far.

Does the metadata in the further call not identify the branch/start time/some other useful info that could help disambiguate this? (honest question)

Re: I hate GitHub Actions with passion

#272

Post by mrinterweb »

modeless wrote: post #238
woodruffw wrote: post #89

I think this post accurately isolates the single main issue with GitHub Actions, i.e. the lack of a tight feedback loop. Pushing and waiting for completion on what's often a very simple failure mode is frustrating. Others have pointed out that there are architectural steps you can take to minimize this pain, like keeping all CI operations isolated within scripts that can be run locally (and treating GitHub Actions fe…

It's insane to me that being able to run CI steps locally is not the first priority of every CI system. It ought to be a basic requirement.

I've often thought about this. There are times I would rather have CI run locally, and use my PGP signature to add a git note to the commit. Something like:

``` echo "CI passed" | gpg2 --clearsign --output=- | git notes add -F- ```

Then CI could check git notes and check the dev signature, and skip the workflow/pipeline if correctly signed. With more local CI, the incentive may shift to buying devs fancier machines instead of spending that money on cloud CI. I bet most devs have extra cores to spare and would not mind having a beefier dev machine.

Re: I hate GitHub Actions with passion

#273

Post by marksomnian »

tracker1 wrote: post #194
maccard wrote: post #64

Earlier quoted context omitted.

> If your CI can do things that you can't do locally: that is a problem. IME this is where all the issues lie. Our CI pipeline can push to a remote container registry, but we can't do this locally. CI uses wildly different caching strategies to local builds, which diverges. Breaking up builds into different steps means that you need to "stash" the output of stages somewhere. If all your CI does is `make test && make…

Ironically, at least for a couple recent projects... just installing dependencies fresh is as fast on GH Actions as the GH caching methods, so I removed the caching and simplified the workflows.

In fact, uv's docs half-suggest this:

> With uv, it turns out that it's often faster to omit pre-built wheels from the cache (and instead re-download them from the registry on each run). On the other hand, caching wheels that are built from source tends to be worthwhile, since the wheel building process can be expensive, especially for extension modules.

https://docs.astral.sh/uv/concepts/cache/#caching-in-continu...

Re: I hate GitHub Actions with passion

#274

Post by anttiharju »

dfee wrote: post #269
anttiharju wrote: post #177

Earlier quoted context omitted.

Second the Nix approach. One can even build a github actions-compatible container out of a flake and have actions run in it. I have done so for my personal projects https://github.com/anttiharju/compare-changes

isn't this better served with something like Bazel (behind Nix of course?)

Could be, not familiar with Bazel. Thanks for mentioning it now can check it out.

Re: I hate GitHub Actions with passion

#275

Post by ted537 »

The main problem with actions is the way they advertise its usage "just put workflows together" is a horrible and non-debuggable way to do things. But even in the tech itself, caching is pretty stingy which can slow dev builds for fairly simple projects because every run will repeat some common work unless you have the cache perfectly configured (did u cover npm, docker, etc. with cache keys correctly?)

Looking at these flaws, running workflows from a persistent VM of ur own becomes pretty tempting because you don't need to copy caches around and can easily SSH in.

Re: I hate GitHub Actions with passion

#276

Post by anttiharju »

SAI_Peregrinus wrote: post #263
anttiharju wrote: post #173

Earlier quoted context omitted.

One can get the ssh access with self-hosted runners but it is problematic because uncovering secrets becomes trivial.

Uncovering secrets is usually trivial. `printenv` in a build script does that pretty reliably.

What do you mean? Simple env prints get masked as *** in logs

I guess one can always just echo the secret to a file and upload-artifact it

Re: I hate GitHub Actions with passion

#277

Post by c-hendricks »

globular-toast wrote: post #226

What always surprises me in these discussions is how few people have used GitLab CI. What gives? It's far, far superior to GitHub and even existed first.

I found gitlab ci's yaml the smallest of the 3 I've used (gitlab, GitHub actions, CircleCI).

But does gitlab ci have anything for sharing? GitHub actions are built around it, and CircleCI has orbs and contexts.

For example, muse's guide for gitlab involves making your own container and managing the cache yourself (ref: https://mise.jdx.dev/continuous-integration.html#gitlab-ci)

GitHub actions is a couple of lines (ref: https://mise.jdx.dev/continuous-integration.html#github-acti...)

Re: I hate GitHub Actions with passion

#280

Post by Imustaskforhelp »

quotemstr wrote: post #244
Imustaskforhelp wrote: post #236

Earlier quoted context omitted.

Yes I believe the same too and I think we are on the same goal. I think that I can probably patch this code to install uv, let's say locally instead of globally if that's a major concern. I feel like its not that hard.

It's easy enough to patch. It's the philosophy that bugs me. We already have a huge problem with routine workflows pulling things from the network (often, without even a semblance of hash-locking) and foregoing the traditional separation between environment setup and business logic. There's a lot of value into having discrete steps for downloading/installing stuff and doing development, because then you can pay speci…

I agree with you and you raise some good points

I think your reason of worrying is either that A) packages can update and contain malware or B) Uv's installation itself. might have malware if any of A) or B) get hacked

Regarding A) I feel like uv's dependencies can be pinned to a certain date to make them reproducible and this can come of help (https://docs.astral.sh/uv/guides/scripts/#improving-reproduc...)

Regarding B) I feel like they provide attestations via GitHub Artifact Attestations and the script could once again be modified to actually verify it via github attestations and they also provide ghcr artifacts (as such immutability) atleast of docker images and I looked further into it and it seems that you can use github artifacts to upload normal binary files as well so I will probably take a look into seeing if I can do something like this for uv's ghcr

Effectively after A) and B) the trust just ends up being reliant on Github's Microsoft infrastructure (usually) and perhaps python infrastructure which is on fastly

But I feel like this is for cases of extremely sensitive workflows But I feel like I might still take a look at it because security still feels very interesting to me and just because of this discussion, I can see at some pointers of following up on curiosity lol

Anyways would love to continue our discussion and probably update you on trying to make a script which could actually be completely pinned (atleast uv binary instead of just running a shell script from the astral servers in such case)

Post reply on HN