Skip to content
Advertisement

In gitlab CI the gitlab runner choose wrong executor

I have the following problem with my Gitlab Pipeline Setup.

I recognized that in the bash there is shown “shell runner” but in the .yml file I used “tags: -docker”. If I re-run the job, sometimes it works and uses the right runner, but most of the time not.

The is the bash output:

Running with gitlab-runner 10.8.0 (079cad9e) on aws-xyz c444133a Using Shell executor... Running on ip-xyz... Fetching changes... HEAD is now at eb4ea13 xyz: removed data retry queue Checking out e0461c05 as backend-tests... Skipping Git submodules setup Checking cache for default-1... Successfully extracted cache $ echo "this is done BEFORE each step" this is done BEFORE each step $ echo "updating server software inside container" updating server software inside container $ apt-get update -y Reading package lists... W: chmod 0700 of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (1: Operation not permitted) E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied) E: Unable to lock directory /var/lib/apt/lists/ W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied) W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied) Running after script... $ echo "this is done AFTER each step" this is done AFTER each step ERROR: Job failed: exit status 1

This is the job in the gitlab-ci.yml file:

backend_test: image: node:6 services: - name: mysql:5.7 stage: test variables: MYSQL_ROOT_PASSWORD: xyz MYSQL_DATABASE: xyz MYSQL_USER: xyz MYSQL_PASSWORD: xyz DBDIALECT: mysql DBDATABASE: xyz DBUSER: xyz DBPASSWORD: xyz DBHOST: mysql DBPORT: "3306" script: - echo "updating server software inside container" - apt-get update -y - apt-get upgrade -y - echo "installing dependencies" - cd api/backend/ - ls -lah - npm install - echo "start testing" - NODE_ENV=test npm run test-code-coverage tags: - docker

Any ideas?

Advertisement

Answer

@edit: From here:

tags is used to select specific Runners from the list of all Runners that are allowed to run this project.

As resolved in the comments, your shell executed must have been tagged with the docker tag, which resulted in him being picked as the executor for the job.

This is my old answer:

You are using a shell executor, and from here:

Shell executor is a simple executor that allows you to execute builds locally to the machine that the Runner is installed

If GitLab Runner is installed on Linux from the official .deb or .rpm packages, the installer will try to use the gitlab_ci_multi_runner user if found. If it is not found, it will create a gitlab-runner user and use this instead. ….
In some testing scenarios, your builds may need to access some privileged resources

Generally it’s unsafe to run tests with shell executors. The jobs are run with the user’s permissions (gitlab-runner) and can “steal” code from other projects that are run on this server. Use it only for running builds on a server you trust and own.

The commands your are running are executed as gitlab-runner user and don’t have permissions to run apt-get command. You can:

  • move to docker
  • grant user gitlab-runner the permissions he needs to run specified commands. gitlab-runner may run apt-get without sudo, also he will need perms for npm install and npm run.
  • grant sudo nopasswd to user gitlab-runner. Add gitlab-runner ALL=(ALL) NOPASSWD: ALL (or similar) to /etc/sudoers on the machine gitlab-runner is installed and change the lines apt-get update to sudo apt-get update, which will execute them as privileged user (root).
7 People found this is helpful
Advertisement