[benatkin]

I disagree that GitHub Actions is much more powerful than GitLab. Both can be helped by a YC company, depot.dev, if you literally mean running containers quickly and reliably. GitHub Actions can be easier to set up if you like having stuff outside of your repo and an OCI image. GitLab may not have the actions library that GitHub has but it can pull docker images and that’s a powerful build library.

[orf]

> I disagree that GitHub Actions is much more powerful than GitLab

It is, by leagues.

Even something simple like running a step before clone/checkout is impossible with Gitlab CI, let alone any of the actual powerful stuff.

[mikepurvis]

GitLab CI can suppress the checkout altogether, do stuff, and then trigger a downstream job.

But really that’s emblematic of the whole thing, where some particular workflow is possible but extremely awkward and hacky. You feel like you’re fighting the system and wish you were just writing whatever it is as a few lines of groovy in a Jenkinsfile.

[orf]

With great power comes great responsibility, and the responsibility to maintain what started out as “a few lines of groovy” is not one I’d ever take up again.

There’s a middle ground between overly flexible and very constrained, and I think GitHub actions nails that.

Individual steps/actions are reusable components with clear interfaces, which is tied together by a simple workflow engine. This decoupling is great, and allows independent evolution.

As a point to this: GitHub actions doesn’t even offer git clone functionality: it doesn’t care about it. Everyone uses the core “GitHub/checkout” action, but there is nothing special about it.

The same for caching - the workflow/steps engine doesn’t give two shits about that. The end result of this decoupling is things like sccache and docker can offer native integrations with the cache system, because it’s a separate thing.

[mikepurvis]

Ah interesting, yeah the whole container build -> CI build has been a long-standing paint point for me across Github, GitLab, and even Jenkins. I will investigate what depot.dev is doing.... cause yeah, proper and intelligent on-demand rebuilding of based containers could be a game changer.

[kylegalbraith]

One of the founders of Depot here. Always feel free to ping me directly (email in my bio) if you ever want to chat more about container builds in general.

[mikepurvis]

For sure! I've always felt like a bit of a loner in that the assumption in most of these platforms is that your build starts with either something barebones (just apt) or maybe your platform only (python3:latest).

However, I've typically dealt with builds that have a very heavy dependency load (10-20GB) where it isn't desirable to install everything every time— I'd rather have an intermediate "deps" container that the build can start from. But I don't want to have to manually lifecycle that container; if I have a manifest of what's in my apt repo vs the current container, it should just know automatically when a container rebuild is required.