.gitlab-ci.yML keywords Complete analysis (A)

To use GitLab’s own pipeline, you must define the content of the pipeline, and the default file to define the content is called. Gitlab-ci.yml, written using the syntax of YML. At present, there are 28 task keywords and 10 global keywords, which overlap a lot. Today I will first explain to you the common keywords, master the use of these keywords, you can write logical rigorous, easy to expand the pipeline.

The 28 keywords of the task are script, after_script, allow_failure, artifacts, before_script, cache, coverage, dependencies, environment, except, extends, image, include, interruptible, only, pages, parallel, release, resource_group, retry, rules, services, stage, tags, timeout, trigger, variables, when

Global keywords image, services, before_script, after_script, tags, cache, artifacts, Retry, timeout, interruptible

The most commonly used tasks are these seven scripts, artifacts, stage, when, tags, image, and cache. Let me introduce these seven keywords in detail.

script

Git clone…. is the shell script that the task will execute, and the script will be executed by runner Clone the current project, because in the pipeline, each job will download the project, restore the cache process, you do not need to script recovery. All you need to do is write your project installation, compile and execute it here, such as NPM install. It is also worth mentioning that the working directory of the script is the root directory of the current project, so it can be developed locally. In addition, scripts can be single or multiple lines

A single script

job:
  script: npm install
Copy the code

Many scripts

job:
  script:
    - npm config set sass_binary_site https://npm.taobao.org/mirrors/node-sass/
    - npm install --registry=http://registry.npm.taobao.org
Copy the code

Script is required for a job. A job must have at least two attributes: job name, job name, and script.

image

Specify a base Docker image as the base runtime environment, often use the image has node nginx Docker

job:
  image: node:latest
  script: npm install
Copy the code

In the above task, if image: node:latest is not specified, an error will be reported when the following NPM install is executed and the command for NPM cannot be found. The role of image is to set up a basic environment for the current task or pipeline, which can be NodeJS, Java, GO, PHP, you can set the pipeline, you can set the task.

artifacts

This word is translated as a product, a finished product, which is used to package and compress some files and folders in the pipeline process, provide an external chain for people to download, and also cache in the subsequent job. Let’s say we build a front-end project and make the DIST directory into a zip package,

build:
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
Copy the code

Tasks running after this task automatically restore the artifact, meaning you don’t have to run NPM run Build to retrieve the compiled Dist file, which is useful when android and ios are packaged, because the pipeline ends up producing a downloadable, installable application. Paths is used to specify which files and directories to place in a workaround. You can also exclude those directories and files using the exclude keyword, supporting regular expressions. There are also several attributes

  • Paths File path
  • Exclude Indicates the excluded file
  • Name Product name
  • Expose_as The exported name on the UI page
  • Untracked type, whether to add a file that Git ignores to the artifact
  • The when on_success; On_failure; Always when to upload products
  • Expire_in Expires in 30 days by default
  • Reports Collects test reports
build:
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    exclude:
      - binaries/**/*.o
    expose_as: 'artifact 1'
    name: "$CI_COMMIT_REF_NAME"
    untracked: false
    expire_in: 2 hrs 20 min
    when: on_failure
Copy the code

tags

Tags keywords are used to specify Runner. The value range of tags is in the Runner tags visible in the project, which can be viewed in Setting =>CI/CD => Runner. You should know that the property can be set globally. If it is not set, the public Runner is used by default to perform pipelining. Each task can specify a Runner, and multiple tags can be specified, but only one Runner can be specified. One shall prevail. Tags are configured when we register Runner and can be changed later.

install:
  tags:
    - hello-vue
    - docker
  script:
    - npm config set sass_binary_site https://npm.taobao.org/mirrors/node-sass/
    - npm install --registry=http://registry.npm.taobao.org
Copy the code

cache

Cache is the storage of some files, some folders in the current working environment directory, which can be recovered during the initialization of each task. Avoiding multiple downloads of the same package can greatly optimize pipeline efficiency. In front-end projects, we often cache node_modules so that a pipeline can use these downloaded packages. Maven downloads are often cached in Java projects. The parameters in the cache are

  • Paths Directory in the current work environment
  • Key stores the key, the key does not regenerate the cache,
  • :key:prefix uses some files to create hash values as part of the key,
  • Untracked Whether to cache files that Git ignores
  • When defines when cache on_SUCCESS is stored; On_failure; always
  • Policy Indicates whether to upload the cache again after the job is completed

Caching can be set globally in the pipeline or in the job

cache:
  key: hello-vue-cache
  paths:
    - node_modules
Copy the code
cache:
  key:
    files:
      - Gemfile.lock
      - package.json
  paths:
    - vendor/ruby
    - node_modules
Copy the code

stage

Stage is used to archive a portion of jobs, which are executed in the order of stages defined. The pre and.post jobs are executed in the order defined by the stage, rather than in the order they were written.

stages:
  - build
  - test
  - deploy

job 0:
  stage: test
  script: echo 'tets'

job 1:
  stage: build
  script: echo 'build'
Copy the code

Build points to job1 before test and job0 after test

when

The when keyword is the implementation of a job that can run in the event of a failure or despite a failure. For example, you need to trigger a job when a task fails, or you need to manually execute a task, or you need to execute another task when one task succeeds.

  • On_success After all tasks are successfully executed
  • On_failure When at least one task fails
  • Always executes the job regardless of the state of the job in its early stages.
  • Manual Manually performs tasks
  • Delayed the execution of the task
  • never

Tasks that are not excluded from execution in Rules are not allowed in workflow: Pipelined by Rules

only/except

Only /except specifies the visible state of the current job. A project has many branches, such as tag. In our assembly line, in order to execute different jobs for specific branches and tags, we need to add this code to the task using only and except. Indicates that the current task is only available on the Master branch

only:
  - master
Copy the code

It can also be triggered by merging, pushing, or using an API, depending on the current code change. If a task has no only property, the default is only: [‘branches’, ‘tags’] Handling branches or tags triggers pipelining.

Write in the last

Understand the above keywords, it is not difficult to write a good assembly line. You can talk to me in private about assembly line problems. demon_0212

Follow me, and there will be more excellent articles to follow.

Starting address www.ebaina.com/articles/14…