Last updated: Aug 04, 2020 17:00
To set up GitLab Runner:
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:
Register the runner to your GitLab ID or specific GitLab projects.
Following is the example registeration procedure on an EC2 ubuntu t2.micro instance:
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/registerCheck 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:
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.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:
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.
- 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.