When running this gitlab.ci yml against a ubuntu VM gitrunner, it fails with the error:
Executing "step_script" stage of the job script
$ sudo apt install which -y
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package which
It is unable to locate the package ‘which’. I have a feeling that which is supposed to be a variable and not a package and is supposed to make some form of identification of what packages to obtain based on the following lines from my gitlab-ci.yaml:
I recently had to rebuild the gitrunner that handles this environment, but I am a little concerned that this gitlab-ci was intended for a docker gitrunner instance and not running it straight out of a VM. Can anyone confirm?
It’s usually a good idea to run sudo apt-get update -y -qq or similar before running apt-get install, that way you make sure your package lists are up to date.
I tried to add the sudo apt-get update and I also tried to install on a docker container but run into permissions errors when I don’t use sudo, and when I do use sudo, it could not find the command. I logged into the bash of the container as root and installed sudo but afterward it gave me this error:
Executing "step_script" stage of the job script
$ sudo apt-get update -y -qq
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
Cleaning up project directory and file based variables
So, image: ubuntu:20.04 means that this particular CI job runs on the ubuntu:20.04 Docker container.
sudo apt install which -y installs the which utility, which is a Unix utility that tells you the location of a binary file that is on your $PATH.
For example:
$ which ls
/bin/ls
$
That error a terminal is required... is to do with running sudo. Most probably you are running as root here anyhow, as that’s the default user for the ubuntu:20.04 image.
If I were you, I’d try removing the sudo from your scripts, and see what happens, and maybe add a line with just whoami somewhere, just to check that you really are root.
Since it defines Ubuntu:20.04 - would it be safe to say this script was intended to be run on docker and not straight out of a VM?
If so, should the script also be written to create the docker container and execute the script after the automated creation? Or should the admin (a human) create the container and register gitlab to it and the script runs from within the container the admin created and registered gitlab to?
This is the output I get from removing sudo and adding a whoami statement:
Executing "step_script" stage of the job script
$ whoami
gitlab-runner
$ apt-get update -y -qq
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
It is running under the user ‘gitlab-runner’
This is all under a docker container incase it matters.
I’m assuming that you are quoting from a .gitlab-ci.yml file. These are run by GitLab runners.
You can use “shared” runners which are “owned” by GitLab, or you can install your own runner and use that. To configure this, go to Settings → CI/CD → Runners in your project.
All of the GitLab shared runners are Docker runners, but in this case, if you choose to use your own runner, you will need to make sure that it is also a Docker runner. This is configured when you create / register a new runner on your own server or VM.
There’s no need to explicitly create a Docker container in the .gitlab-ci.yml file in this case, because the configuration image: ubuntu:20.04 will ensure that the runner creates the container for you.
I see, in this case… …would the appropriate way to handle this be installing Docker on a Ubuntu VM, but allowing the GitLab runner to create a container?