Page tree
Skip to end of metadata
Go to start of metadata

Last updated: Dec 02, 2019 16:25

GitLab is a reliable, secure and easy to use public Git solution for global developers. Compared to the traditional GitHub, GitLab offers unlimited private repositories to  users for free. This is a valid reason to choose GitLab over GitHub. GitLab also offers a built-in CI/CD feature to save the license cost for a CI tool and the effort to connect a 3rd party tool to Gitlab. This is the icing on the cake.

Let's look at how to enable this CI/CD feature for your projects. A sample project is available here: https://gitlab.com/perfectops/quantum-bmo-sitesavailabilitycheckup

1 | Prepare GitLab Runner (optional for Docker users)

Just like the slaves of Jenkins or Building Agents to Bamboo, the Gitlab CI/CD solution also 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).

On this page:

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:

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.

    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
    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.


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: