Live data from Hacker News

The Pain That Is GitHub Actions

feldera.com

581–584 of 584 posts

Re: The Pain That Is GitHub Actions

#581
post #362

Earlier quoted context omitted.

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.

GitLab drives me insane with this. My runner is on a 5 year old alienware desktop with an nvme ssd and all the trimmings but loading an uncompressed cache from the same local disk takes ten goddamn minutes. No matter what, all of my jobs take five to ten minutes just to start up.

Re: The Pain That Is GitHub Actions

#582

We've all been there: $ git l * cbe9658 8 weeks ago rejschaap (HEAD -> add-ci-cd) Update deploy.yml * 0d78a6e 8 weeks ago rejschaap Update deploy.yml * e223056 8 weeks ago rejschaap Update deploy.yml * 8e1e5ea 8 weeks ago rejschaap Update deploy.yml * 459b8ea 8 weeks ago rejschaap Update deploy.yml * a104e80 8 weeks ago rejschaap Update deploy.yml * 0e11d40 8 weeks ago rejschaap Update deploy.yml * 727c1d3 8 weeks ag…

Better formatting

  $ git l 
  * cbe9658 8 weeks ago rejschaap (HEAD -> add-ci-cd) Update deploy.yml 
  * 0d78a6e 8 weeks ago rejschaap Update deploy.yml 
  * e223056 8 weeks ago rejschaap Update deploy.yml 
  * 8e1e5ea 8 weeks ago rejschaap Update deploy.yml 
  * 459b8ea 8 weeks ago rejschaap Update deploy.yml 
  * a104e80 8 weeks ago rejschaap Update deploy.yml 
  * 0e11d40 8 weeks ago rejschaap Update deploy.yml 
  * 727c1d3 8 weeks ago rejschaap Create deploy.yml

Re: The Pain That Is GitHub Actions

#583

Earlier quoted context omitted.

This is true because your CI steps will be running on a lower number of physical machines, ensuring higher cache hits?

Kind of - you can also pin runners.("This workflow runs on this runner always"). And caching just means not deleting the artifacts from the file system from the previous runs. Imagine building Android - even "cloning the sources" is 200GB of data transfer, build times are in hours. Not having to delete the previous sources and doing an incremental build saves a lot of everything.

Gitlab also has some tips here: https://docs.gitlab.com/ci/caching/ on using shared caches, which can help in some scenarios, especially runners in Kubernetes that are ephemeral, ie. created just before a job starts and destroyed afterward.

tldr; "A cache is one or more files a job downloads and saves. Subsequent jobs that use the same cache don’t have to download the files again, so they execute more quickly."

It will probably still be slower than a dedicated runner, but possibly require less maintenance ("pet" runner vs "cattle" runner).

Re: The Pain That Is GitHub Actions

#584
post #474

Earlier quoted context omitted.

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.

Not a hater - nobody will contest that Docker was a huge success, congrats... I just don't think Dagger has legs tbh.
Post reply on HN