It's git, so everyone has a copy of the repo. You can continue collaborating with send-email or some random SSH server. That's the beauty of a DSCM.
(They start to ruin that, but lets say, the idea is still visible.)
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.
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
It would be nice if it had better integration with existing package managers like pip, cargo, npm and so on though. Vendoring your dependencies is fine for a big project like Chrome or Android or your company monorepo; it's a bit annoying for a small CLI tool or whatever.
Another option is something like Landlock Make, but I haven't tried it.
Granted, those build instance pull from the central git repo, and are triggered from GitLab... so also, no.
If you plan on a GitLab mirror, including the Git repository and groups/projects, the direct transfer migration can be helpful https://about.gitlab.com/blog/2023/01/18/try-out-new-way-to-...
GitLab Geo can be an alternative for larger, high-availability setup requirements. https://docs.gitlab.com/ee/administration/reference_architec...
http://Xkcd.com/303 but for GitHub is down.
For example on my team we have a few devs who push patches from laptop directly to their work desktop, as a part of day-to-day synchronization. No central ssh server involved.