CODEWITHSUNDEEP
dockergitlabgitlab-cigitlab-ci-runnerdocker-in-docker
Bugpirasi
Bugpirasi

Reputation: 423

Gitlab-Runner: Permission denied on cloning from master

I was looking for a method to implement a CI/CD pipeline within my projects. I decided to use Gitlab with its gitlab-runner technology. I tried to use it through docker containers but, after more than 100 attempts, I decided to install it on the machine.

I followed the official Gitlab guide step by step. Everything is working perfectly; I run the register, fill all the fields correctly and I go on to write the .gitlab-ci.yml:

image: docker:latest

services:
- docker:18.09.9-dind

stages:
  - deploy

step-deploy-prod:
  stage: deploy
  only:
    - master
  script:
    - docker-compose up -d --build
  when: always
  environment: master

As you can imagine when looking at the yml file, when some operation is performed on the master, the pipeline starts and executes a docker-compose up --build -d (the project in question is a PHP application with a SQL database deployed through a compose).

First run: Absolutely perfect; the pipeline starts, the build is executed correctly and is correctly put in online

Second and following 140 runs: That's the nightmare. Over 140 builds failed for the same reason; when cloning the repository, the runner doesn't seem to have write permissions on his home directory (/home/gitlab-runner/builds/...).

enter image description here

If I manually delete the nested folder inside builds/ the runner works, but only for one run, then same situation.

I tried to:

Upvotes: 3

Views: 3622

Answers (1)

hdd42
hdd42

Reputation: 66

You always should not forget to stop your containers with after_script section.

But in your case, you can use GIT_STRATEGY to clear repository before your job.

  variables: 
    GIT_STRATEGY: none

Your yml file with this fix

image: docker:latest

services:
- docker:18.09.9-dind

stages:
  - deploy

step-deploy-prod:
  stage: deploy
  only:
    - master
  script:
    - docker-compose up -d --build
  when: always
  environment: master
  variables: 
    GIT_STRATEGY: none

Upvotes: 2

Related Questions