[CICD] How to write .gitlab-ci.yml file

⏳ CICD refers to continuous integration/continuous delivery (continuous integration/continuous delivery), which is a software development idea proposed to meet the needs of Internet and financial companies for rapid iteration projects. The general idea is to write automated scripts so that new code must pass some rule checks before it can be deployed online.

.gitlab-ci.ymlGitlab is an excellent platform for implementing the CICD process. It configures the CI process by writing files in the root directory of the project , mainly describing how the project is compiled .

1. Stages

The stages parameter defines the stages that the code goes through to pass through the pipeline, and is used by all jobs.
If stages are not defined in the file, the three stages of build, test and deploy are included by default.

stages:
  - lint
  - test
  - build

The above is a definition of the stages parameter. The effect in gitlab is as follows, which means that the release is considered successful only after passing the inspection of these three stages, so it is vividly called the pipeline .

Two, job

job can be translated as "job", which is .gitlab-ci.ymlthe basic unit of a file. Its basic definition is:

job_name:
  stage: lint
  script:
    - xxx
    - xxxx
  other_param: xxx

The job name is declared first, and then some of its parameters are declared internally. A parameter, as declared above stage, indicates that the job is bound to lintthe stage.
job is the top-level element in the file and contains at least one scriptstatement. If a job is not explicitly associated with a stage, it is associated with testthe stage by default.

2.1 Other parameters in the job

• image specifies the Docker image used;
• before_script defines the commands to be executed before the job, such as installing dependencies, printing debugging information, and the like;
• Variables can be divided into global variables and job-level local variables according to different locations. Local variables will overwrite family variables with the same name within the job;

# 全局变量
variables:
  DATABASE: xxxxxxxx

# 作业级局部变量
job_name:
  variables:
    DATABASE: xxxxx

There are special variables related to git strategy in variables, eg GIT_SUBMODULE_STRATEGY, how to import submodules in git. The default value is none, that is, no submodule is imported; normalit means that only the topmost submodule will be imported when the submodule is pulled; recursiveit means that all submodules will be recursively imported.

• retry means that when the job fails, it can be re-executed. There are only three values: 0, 1, and 2. There are also two attributes, maxand , that can be configured under it when, indicating the maximum number of retries and when to retry;