Either use Depot or switch to self-hosted runners with large disks.
GitLab CI is leaps and bounds ahead.
Zoom is adding in email.
Years ago I worked for a bank. You know what happens if you set up bill pay with a bank? You're unlikely to end that relationship. Because who the fuck wants to do all that work to move.
Your labor, your suffering (cause setting up bill pay sucks) is an egress fee.
If you have GitHub acting as anything other than your public facing code repo you're locking yourself into the platform. Bug tracking, code review, CI pipelines, GitHub features that are going to keep you from moving quickly if you need to change providers.
It's trivial to switch from github to codeberg for example… So I don't think it's that bad to be honest.
The runner code is on GitHub, and it's not pretty. In fact last time I ran it it had trouble generating stable exit codes.
Now I don't even want to imagine what Github Actions are like…
If there's one thing I've learned over the years, is that we really seldom have advanced needs. Mostly we just want things to work a certain way, and will fight systems to make it behave so. It's easier to just leave it be. Like maven vs gradle; yes, gradle can do everything, but if you need that it's worth taking a step back and assess why the normal maven flow won't work. What's so special with our app compared to the millions working just fine out of the box?
We tried caching at several companies. Outside node builds, it was never worth it. Horray, our .Net builds took 15 seconds instead of 4 Minutes. Eventually you realized no one cared since we averaged deployments every 4 days outside of outages and time being burned by it just wasn't there.
A clean build on a 16 core machine with an SSD and a GB network is about 4 hours including checkout.
Our cached builds are 15 minutes including deployment.
It's not even that! Coming from GitLab I was quite surprised at how poor the "getting started" experience was. Rather than a simple "on push, run command X" you first have to do a deep dive into actions/events/workflows/jobs/runs, and then figure out what kind of weird tooling is used for trivial things like checking out your code, or storing artifacts.
And then you try to unify your pipeline across several projects because that's what Github is heavily promoting with the whole "uses: actions/checkout" reuse thing - but it turns out to be a huge hassle to get it working because nothing works the way you'd expect it to work.
In the end I did get GHA to do what I was already doing in GitLAb, but it took me ten times as long as it did originally setting it up. I believe GHA is flexible and powerful enough to be well-suited for medium-sized companies, but it's neither easy enough for small companies, nor powerful enough for large companies. It's one of the few Github features I genuinely dislike using.
There's also an action out there "GitHub cache dance" that will stick your whole buildkit state dir into the gha cache.
It's just a problem that requires big, local disks to solve.
docker/nerdctl only transfers the context, everything else is cached on the builder. it's very useful for monorepos (where you usually want to build and tag images for every tested commit)
and the builder directly pushes the images/tags/layers to the registry. (which can be just a new tag for already existing layer.)
a noop job is about 2 sec on GitLab CI this way.
sure, it should work nicely. (I just prefer the local disk, it's just a cache after all.)