preface

Gitlab-ci is a continuous integration system for the use of GitLab. Gitlab-ci is integrated by default and enabled by default in versions after GitLab8.0.

Continuous integration is a software development practice in which team development members integrate their work frequently, usually at least once a day per member, which means that multiple integrations may occur per day. Each integration is verified by an automated build (including compilation, release, and automated testing) to find integration errors as quickly as possible. Many teams find that this process greatly reduces integration problems, allowing teams to develop cohesive software more quickly.

Basic CI workflow

Gitlab-ci is triggered when we push code to the remote branch:

  1. Execute automated scripts to build and test projects
  2. If the test passes, review can be carried out; If not, the first step is executed again after modification and push again
  3. If review passes, the Merge code executes the automation script again to inspect the project and deliver it

.gitlab-ci.yml

To use gitlab-ci, first add.gitlab-ci.yml in the root directory, which records the operations that CI needs to perform. When a CI operation is triggered, gitlab-CI reads the information in.gitlab-ci.yml.

This is a YAML file, so you must pay special attention to indentation. Always use Spaces, not tabs.

Here are the main elements of gitlab-ci.yML.

Job

Job is the most basic element of the.gitlab-ci.yml file.

  • Job defines the constraints, under what conditions
  • Job is a top-level element with an arbitrary name (reserved words need to be avoided) and has at least one script substatement
  • The number of jobs is not limited
Job1: script: "execut-script-for-job1" // single substatement job2: script: // multiple substatements -bundle exec rspeca -bundle exec rspecbCopy the code

Each Job runs independently of each other in Runner(i.e. Gitlab-runner, as described below), and multiple jobs form the Pipeline configuration steps of CI.

The keyword

In addition to script being the only required key for a Job, there are other keywords:

  • Environment Is used to define the environment in which jobs are deployed
  • Image is used to specify the Docker image for the Job
  • Stage Is used to define the stage and global key of the JobstagesWhen used together, the same can be executed in parallel in a particular environmentstageThe Job of
  • Timeout Indicates the timeout period of the Job
  • Rules Is used to judge jobs. One of theifAttributes can be based on variables$CI_PIPELINE_SOURCETo judge
  • .

More keywords can be queried here.

Global key

In addition to defining keywords for each Job, you can also define global keywords.

  • Stages Defines all stages that contain jobs. The order of elements determines the order in which jobs are executed
stages:
  - build
  - test

ob 1:
  stage: build
  script: make build dependencies

job 2:
  stage: build
  script: make build artifacts

job 3:
  stage: test
  script: make test
Copy the code
  • You can also usedefaultTo define some default values for all jobs.
Default: image: ruby:2.5 rspec: script: bundle exec rspec rspec 2.6: image: ruby:2.6 bundle exec rspecCopy the code
  • There are other global keywords that can be viewed here

GitLab-Runner

Gitlab-runner is used in conjunction with Gitlab-CI, and is a thing used to execute software integration scripts, which can be virtual machines, VPS, bare metal machines, Docker containers, or even a group of containers.

GitLab notifies GitLab-CI when there are code changes in GitLab (such as push code). The Gitlab-CI then finds and notifies the associated Gitlab-Runner, who downloads the project code locally and executes the pre-designed script.

There are two types of Gitlab-runners: Shared runners and Specific runners.

  • Shared Runner requires an administrator to install and configure it, which is common to all projects, but it is best to set up different Docker images in yML files to distinguish them
  • Specific Runner can be installed and configured by people with project permissions, and is private to each project

Install GitLab – Runner

Before we can use GitLab-Runner, we need to install it. There are three ways to install Gitlab-Runner: using Docker, manually downloading binaries, or using a repository of RPM/DEB packages.

Here we briefly describe the private Gitlab-Runner installation:

Note: Since Windows 10-64-bit was used as the test server in the project, the private Gitlab-Runner installation and the following registrations are based on this server, please refer to other environmentswebsite.

  1. Create a folder somewhere in the system, for example:D:\GitLab-Runner.
  2. Download exe file (x86 can download this)
  3. To download thegitlab-runner-windows-amd64.exefilerenamegitlab-runner.exeAnd move toD:\GitLab-RunnerIn the

Registered GitLab – Runner

At this point, the preparation is complete and the registration of Gitlab-Runner needs to begin. Registration for Gitlab-Runner is requiredGitLab Project - Setup -CI/CD-RunnerTo obtain the Gitlab-Ci Coordinator URL and token:

After obtaining the relevant information, you can register execution in CMD:

  1. Open theD:\GitLab-RunnerAnd then typegitlab-runner.exe registerAnd press enter
  2. Enter the Gitlab-ci Coordinator URL to find the corresponding Gitlab
  3. Enter token to register Runner
  4. Enter the description of the Runner
  5. Enter Runner’s tag, separated by commas
  6. Enter Runner’s execution scenario, and here I chose Sell

Of course, the specific configuration according to their respective projects to determine, you can refer to the official website.

After registering, you can find the config.toml file in D:\ gitlab-runner, which is the Runner configuration file.

Start the service

You can start the Runner service directly:

./gitlab-runner.exe run
Copy the code

You can also set Runner as a system service:

Exe install --user ".\ enter-your-username "--password" enter-your-password "// Start the service /gitlab-runner. Exe start // Suspend service./gitlab-runnerCopy the code

After the service is started, theGitLab Project - Setup -CI/CD-RunnerRun the following command to check the current Runner status:

pipelines

When Runner is configured, we can add.gitlab-ci.yml to the branch for a simple test:

// .gitlab-ci.yml
build:
  tags:
    - test-master
  script:
    - npm install
    - npm run build
Copy the code

We push the modified code to the remote GitLab, where it is availableCI/CD-pipelinesSee the current CI execution state:

Click the state in charge to check the execution status of all jobs:

Click Job to view the detailed process of the Job:

conclusion

When using Gitlab for code versioning, you can use Gitlab-CI for continuous integration.

Before using gitlab-ci, you need to complete the configuration of.gitlab-ci.yml and Gitlab-runner. In charge, continuous integration is triggered during push and merge operations. You can check the progressive status in charge.

reference

  • Gitlab.gitlab.ci.yml — official website
  • Gitlab CI uses advanced techniques
  • Practice of FRONT-END engineering CI/CD based on GitLab CI