Creating your own Personal GitLab Runner

Resources

• GitLab Runner Docs
• Docs on various GitLab Runner Executors
• GitLab CI Pipeline Configuration Docs
• Predefined Environment Variables for builds

Setting up your own personal GitLab Runner

To help you get up and running with GitLab CI, the following steps can be followed to help you set up a GitLab Runner on your own personal device. Note that this runner should not be used to support actual team builds, but can be a great way to experiment how to work with builds.

1. Create a new GitLab repo in your own personal namespace. Name it gitlab-runner-demo.

2. If you don’t see the CI/CD menu in the left-hand nav, enable Pipeline support for the repo.

   1. Go into Settings -> General.
   2. In the Visibility, project features, permissions section, enable Pipelines.
   3. Click Save changes
   4. Verify that the “CI/CD” menu option now appears.

3. Go into Settings -> CI/CD and expand the “Runners” section. We will need values from this in the next steps.

4. Register your runner!

   1. Run the following command to start the registration process.

      docker container run --rm -ti \
          -v ${PWD}:/etc/gitlab-runner \
          gitlab/gitlab-runner register
      

   2. For the “gitlab-ci coordinator URL”, enter the URL in the instructions. (https://code.vt.edu)

   3. For the “gitlab-ci token for this runner”, enter the registration token displayed on the settings page.

   4. For a runner description, enter something like “[Your Name]’s Personal Runner”. This will be used in the GitLab interface, so should be a name you’d recognize.

   5. For tags, you can leave this empty for now. Tags allow you to target specific runners for specific jobs.

   6. For the executor, enter “docker”.

   7. For the default image, you can really put anything, as we will be specifying the exact image in each stage of our builds. I typically use “docker:stable”.

5. Refresh the repo’s settings page and make sure your new runner shows up on the project. Most likely, it will show us activated, but that it has not connected yet.

6. If you look in the directory you ran your registration, you should see a config.toml file. We’re going to modify it to not run builds “Docker-in-Docker”, but directly on the host. When builds start, each job will run in a separate container. We need to mount the Docker socket into the container to let it talk to the engine on the host.

   1. In the runners.docker section, modify the volumes to have the value ["/cache","/var/run/docker.sock:/var/run/docker.sock"]. This is something we’re doing for only our local/test and shouldn’t be done for real pipelines (where you should use Docker-in-Docker).

7. Now, let’s start up our runner! After a few seconds, you should see a green ball next to your now-running runner!

   docker run -d \
       -v ${PWD}:/etc/gitlab-runner \
       -v /var/run/docker.sock:/var/run/docker.sock \
       gitlab/gitlab-runner
   

8. Let’s create some files and a simple build!

   1. Create a basic index.html file with some “Hello world” text

   2. Create a Dockerfile with the following:

      FROM nginx:alpine
      COPY index.html /usr/share/nginx/html
      

   3. Create a .gitlab-ci.yml file with the following:

      stages:
        - build
             
      build:
        stage: build
        image: docker
        script:
          - docker build -t my-first-nginx-app .
      

      Once you commit this, you should see a build kick off!

9. Back on your machine, start your app!

   docker run -dp 80:80 my-first-nginx-app
   

   And open your browser to http://localhost!