Hi @rbouchard Welcome to the GitLab community!
Let me help you understand this.
For some context, GitLab.com shared runners use autoscaling docker executors, so each job runs in a separate ephemeral VM that starts a docker container, and all commands in a CI job execute inside that docker container. This means every job you run operates in an isolated space, like a tiny virtual machine for your code to play in. Because of this, all commands/packages you need for the CI job must either be baked-in to the image or installed as part of the CI job.
The error you’re facing:
$ sudo usermod -aG docker $USER
/bin/bash: line 125: sudo: command not found
Tells us that
sudo isn’t available in your container. That’s because Docker containers are usually stripped down to the essentials, and
sudo often isn’t one of them.
You could try to install
sudo in the container, but that’s probably not the best solution. Why? Because the shared runners on GitLab.com already run as
sudo probably isn’t really needed. Plus,
sudo usually asks for a password, and in our non-interactive CI job environment, there’s no way to input one.
Since you’re already
root , you should be able to run
usermod -aG docker $USER without any problem. This is, of course, if there’s a
docker group in your container. If not, you’ll need to create it or you’ll get a
usermod: group 'docker' does not exist error.
I usually see
sudo usermod -aG docker $USER as a setup step for running Docker containers without
root. Since .com shared runners already run docker images and they already have
root access, I’m not sure if this is necessary or desirable.
To help you better, could you share more details about your project and what you’re trying to build? This will allow me to provide a more tailored solution.