To set up GitLab Runner:

1. Download and set up GitLab Runner programs on the runner computers or VMs. Refer to GitLab docs to find out how to install GitLab Runners: https://docs.gitlab.com/runner/install

   Because you may want your runner to be up and running all the time to accommodate random build runs, we suggest that you set up the runner with a cloud VM service, such as AWS EC2. Following is the example install procedure on an EC2 ubuntu t2.micro instance:

   

2. Register the runner to your GitLab ID or specific GitLab projects.
   When you have GItLab Runner installed on the designate runner PCs, you can run a procedure to register your runner to the GitLab user or project. Refer to the GitLab Runner documentation for the commands to register your runner to GitLab: https://docs.gitlab.com/runner/register

   Following is the example registeration procedure on an EC2 ubuntu t2.micro instance:
   

3. Check the runner status from GitLab Settings > CI/CD section.

   If the registeration procedure was successful, your custom runner should show a green status in the GitLab settings. For example:

    Click to view example

   

2 | Prepare your Docker image

Although you can use other executor technologies to run your builds, the Docker is the easiest and the most straightforward. For help with preparing a working Docker image, you can refer to A dockerized Quantum-JS package for easily portable and deployment.

A requirement to the docker image is that the image is located in a publicly available docker registry, such as dockerhub. The docker image should contain all the necessary components to build your project. For instance, to run a Quantum project, the docker image should contain JDK, Maven, Git, openssh, and so on.

The Dockerfile should look more or less like the following:

FROM openjdk:11-jdk
ARG ssh_pub_key
ARG ssh_prv_key
ARG netrc
ARG MAVEN_VERSION=3.5.4
ARG USER_HOME_DIR="/home/myuser"
ARG SHA=ce50b1c91364cb77efe3776f756a6d92b76d9038b0a0782f7d53acf1e997a14d
ARG BASE_URL=https://apache.osuosl.org/maven/maven-3/${MAVEN_VERSION}/binaries
RUN mkdir -p /usr/share/maven /usr/share/maven/ref \
  && curl -fsSL -o /tmp/apache-maven.tar.gz ${BASE_URL}/apache-maven-${MAVEN_VERSION}-bin.tar.gz \
  && echo "${SHA}  /tmp/apache-maven.tar.gz" | sha256sum -c - \
  && tar -xzf /tmp/apache-maven.tar.gz -C /usr/share/maven --strip-components=1 \
  && rm -f /tmp/apache-maven.tar.gz \
  && ln -s /usr/share/maven/bin/mvn /usr/bin/mvn
RUN apt-get update && apt-get install -y openssh-server
RUN useradd -ms /bin/bash myuser
ENV MAVEN_HOME /usr/share/maven
ENV MAVEN_CONFIG "$USER_HOME_DIR/.m2"

3 | Prepare .GitLab-CI.yml

When the docker image has successfully built and been pushed to a public docker registry, we can go ahead to set up the CI/CD procedure for the project in GitLab. The GitLab CI/CD procedure is controlled by this .gitlab-ci.yml file. 

To prepare the file:

1. In the Project panel, click Set up CI/CD.

    Click to view image

   

   GitLab will open an editor to edit a new file named .gitlab-ci.yml, a YAML file. 

2. Edit the file as needed. For detailed keywords and syntaxes, see https://docs.gitlab.com/ee/ci/yaml/README.html. Following is an example of a Maven run in a pre-prepared Docker image:

   Sample CI/CD procedure  Expand source

   image: denghj/quantumexe:1.0
   
   checkup:
    script: "mvn -f pom_checkdevices.xml -DSEC_TOKEN=$K8S_SECRET_TT -DREPORT_DRIVER_DEVICEID=$K8S_SECRET_DEVICEID -DJOB_NUM=$CI_JOB_ID -Dmaven.repo.local=.m2/repository clean test"
    only:
    variables:
    - $RUNTYPE == "checkup"
   boot:
    script: "mvn -f pom_bootdevices.xml -DSEC_TOKEN=$K8S_SECRET_TT -DREPORT_DRIVER_DEVICEID=$K8S_SECRET_DEVICEID -DJOB_NUM=$CI_JOB_ID -Dmaven.repo.local=.m2/repository clean test"
    only:
    variables:
    - $RUNTYPE == "reboot"

   This sample CI/CD procedure contains two separate jobs due to the different run schedules: 

   • checkup runs one specific .pom file in the project to check up all 80+ cloud device availabilities.
   • The boot job reboots and recovers about 30 mission-critical devices in a customer's cloud.
3. To specify which job runs on which Runner, add tags to each job in the .gitlab-ci.yml file.

4 | Schedule the job runs

In the GitLab project, in the CI/CD section, you can schedule your build jobs instead of triggering them by committing/pushing new changes to the repo.

 Click to view image

In the New Schedule window, you can specify the variable to control which job to run. Use the traditional unix cron syntax to control when the jobs will be running.

 Click to view image