Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”.

preface

Hello everyone! I’m front-end nameless

background

A few years ago, as a white guy, I just needed to write the front-end code in peace, and the front-end code deployment was directly entrusted to the operation and maintenance personnel to deploy, which server to deploy, these do not need to care about.

Suddenly, the operation and maintenance staff quit, there was no way, the business needs another project, without the operation and maintenance staff, we can only compile locally every time, and then manually synchronize to the server directory, tired dog! Tired to find a way to solve.

GitLab CI

We often have a.yML file in our projects, and many people don’t know what this file is for.

GitLab CI/CD (hereafter referred to as GitLab CI) is a set of CI/CD system based on GitLab, which allows developers to configure CI/CD process in the project through.gitlab-ci.yml. After submission, the system can automatically/manually execute tasks. The CI/CD operation is complete.

To put it more simply, the function of this YML file is that after we submit the code to GitLab, GitLab CI will automatically read the content in the YML file and perform corresponding operations. Gitlab is just a code repository. To implement CI/CD, we need to install Gitlab-Runner. A Gitlab-runner is the equivalent of a task executor.

Download and install

For example, we installed Git-Runner on the test server (9.138)

First we download and install git-runner

# download
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 
# grant execute permission
sudo chmod +x /usr/local/bin/gitlab-runner
Create a CI user
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash 
Install and run the service
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start
Copy the code

Registered runner

GitLab view the runner

Use registered runners

Compile. Gitlab-ci. yml file, first understand some basic concepts

1. Pipeline

A Pipeline is actually a build task, which can contain multiple processes, such as installing dependencies, running tests, compiling, deploying test servers, deploying production servers, etc. Any submission or Merge Request can trigger a Pipeline, as shown below:

2. Stages

“Stages” refers to the construction stage. Specifically, it is the process mentioned above. We can define multiple Stages in a Pipeline. These Stages have the following characteristics:

  • All Stages run in order, that is, when one Stage is complete, the next Stage begins
  • The Pipeline will be successful only when all Stages are complete
  • If any of the Stages fails, the Stages that follow do not execute and the build task fails

Therefore, the relationship between Stages and Pipeline is:

2. Jobs

Jobs stands for build work and represents work performed within a Stage. We can define multiple Jobs in Stages, which have the following characteristics:

  • Jobs in the same Stage execute in parallel
  • The Stage succeeds only when Jobs in the same Stage all execute successfully
  • If any Job fails, the Stage fails, that is, the build task fails

Therefore, the diagram of Jobs and Stage is:

So let’s write a simple.gitlab-ci.yml

Pay attention to

Git must be installed on the server where git-runner is installed, or you may see an error:

After the language

Your comments are welcome. Project templates are constantly being optimized, like every time! Comments are welcome.