[hakre]

But they are clever, you can have the runner local.

(They start to ruin that, but lets say, the idea is still visible.)

[IshKebab]

Yeah you can't really. It doesn't support a ton of syntax and features.

And they also said they were going to remove that ability too. Tbf to them after the inevitable response they did say they will come up with a proper solution, though that was some time ago.

Obviously the real solution is to use Bazel and not to use Gitlab CI as a crap build system.

[dijit]

Bazel seems like a good idea but it's far too immature to actually work in the FOSS world, almost none of the external _rules are google quality, and it damn near requires a PhD to set up properly.

I spent a good few months learning it and it's not the tool I would reach for in almost any circumstance unfortunately.

Docs are also lacking, which is certainly not a problem with GitlabCI

[hakre]

Yeah, why not? But often GNU Make is fine for incremental builds.

[slowmovintarget]

If by local you mean local to a cloud instance that runs automated builds on every merge for specific branches, then yes.

Granted, those build instance pull from the central git repo, and are triggered from GitLab... so also, no.

[hakre]

local like in tree.

[mdaniel]

Only for `script: "echo hello world"` style jobs; anything more real makes `gitlab-runner exec` a total farce