GitLab

Just like the agents of Jenkins or Building Agents of Bamboo, the Gitlab CI/CD solution requires you to prepare a proper runner to run your builds. You can set up the Gitlab runner on almost any platform (Windows, Linux, Mac, and so on).

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 registration procedure was successful, your custom runner should show a green status in the GitLab settings.

Although you can use other executor technologies to run your builds, the Docker is the easiest and the most straightforward.

A requirement to the docker image is that the image be located in a publicly available docker registry, such as dockerhub. The docker image should contain all 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"

When the docker image has successfully built and been pushed to a public docker registry, you can 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.

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

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

   Copy

   Sample CI/CD procedure

   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.

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.

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.