For some reason, different parts of the Gitlab CI software expect different names for the runner binary-- possible names are gitlab-ci-multi-runner and gitlab-runner.

If you set up a runner in a VM and want to upload artifacts, for some reason Gitlab CI requires you to install gitlab-ci-multi-runner on the VM guest (even though it is the host that is actually the runner). But when you do that, you have to actually go through the entire build process before seeing a non-terminal error that gitlab "couldn't find gitlab-runner". So now you have to go in on the VM guest, manually create a symlink from gitlab-ci-multi-runner to gitlab-runner, take a new snapshot of the VM state, and artifact upload will now work.

I say "non-terminal" above because a failure to upload the artifact doesn't fail the build. So you can be looking at all checkmarks for everything in your pipeline and have no idea for which of those jobs you actually got artifacts.

Also, every once in awhile I'll get failed builds where there is nothing at all in the build log. Typically, clicking "Retry" will successfully start a new build and complete successfully.

Also, there is no way to specify to gitlab to keep only the last N artifacts.

On the positive front, I finally figured out a way to set up an ssh server from within the msys2 environment in Windows, which requires no development whatsoever on the gitlab-ci infrastructure. That means gitlab-ci will ssh into msys2 on the runner, giving me a POSIX-y build environment on all my platforms. So that's nice.

Sorry if this sounds overly negative and like a poor substitute for actually filing bugs. But the last time I worked on fixing a bug it took months for the maintainer just to click a button. This seems to be the only place I get timely response.