Setting up Drone CI to work with self hosted Gitlab Repository

I have already setup Gitlab CI to build docker images which I'll be covering in a separate post. I may not have posted it to dev.to but you'll be able to find some material if you search on my blog.

I had successfully setup Drone CI to work with Gitea. However, I ran into trouble getting it to work with a Gitlab repository. Most of the problems result from SSL certificate configurations and proxy configurations in a self-hosted environment.

First off, once drone was connected to Gitlab repositories, it was able to sync the repositories. The problem came when I attempted to activate the repository for automated builds in Drone. I got the message failed to activate your repository and check this. Following the steps in that post did not resolve the issues for me. As always, I had a suspicion this is something related to communication between Gitlab and Drone not working because of SSL certificate not being configured correctly. Setting the DRONE_LOGS_DEBUG=true in my drone server and inspecting the logs gave some insight.

The problem was that Drone CI was attempting to create a webhook via Gitlab API that will be triggered everytime a commit occurs on the repo to trigger a build in Drone. However, it was not getting a response. This is related to a Gitlab setting that prevents Outbound requests from Gitlab. The solution is described here. You have to enable requests to the local network from web hooks and service.

Once this is done. You should be able to activate the repository in Drone. However, we're not done yet.

Even if the Omnibus docker distribution of Gitlab has the custom SSL certificates mapped, these are not applied to the webhooks (or atleast I haven't figure out yet how to make them be used by Gitlab webhooks for verification). Also by default, the project specific webhook created by Drone in Gitlab to trigger builds has SSL verification enabled by default. This results in the error ad depicted below.

The simple solution is to disable SSL verification at this point if you're OK to do that in your environment.

The last part you need to ensure is that all the required runners required for your projects have been configured correctly. For the docker image build and deploy setup, I require a docker-exec-runner and a docker-runner.

The final drone configuration for building a docker image and deploying via docker-compose on the same host is as follow. Deployment on other hosts could be achieved by tweaking the commands to login to remote host via ssh and perform the same actions.

kind: pipeline
type: docker
name: build
#cd
steps:
- name: publish
  pull: if-not-exists
  image: plugins/docker
  settings:
    registry: registry.mydomain.net
    username:
      from_secret: username
    password:
      from_secret: password
    repo: registry.mydomain.net/my-project
    tags: 
      - latest
    insecure: true
--------
kind: pipeline
type: exec
name: deploy

# Cloning the respository in deploy stage is necessary to copy docker-compose.yml
# clone:
# disable: true

steps:
- name: deploy
  environment:
    USERNAME:
      from_secret: username
    PASSWORD:
      from_secret: password
  commands:
  - echo $(pwd)
  #Be careful with command below to not overwrite an existing project
  - mkdir -p /home/docker/services/my-project
  - cp docker-compose.yml /home/docker/services/my-project/docker-compose.yml
  - cd /home/docker/services/my-project
  #Notice below the synatax for using environment variables source in the environment command above
  - docker login -u $USERNAME -p $PASSWORD registry.mydomain.net
  - docker-compose pull && docker-compose up -d
depends_on:
  - build

The Dockerfile that will be used in the build step must reference an image from the private repository if it does not have access to public docker repository.

FROM registry.mydomain.net/nginx:alpine
COPY /build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]