Easy to understand, automated deployment guide for front-end teams – Configuration chapter

Gitlab-ci. yML file configuration tutorial, so that you can easily use the CI program to automate the deployment of front-end team projects, if you have not read the previous article, please pay attention to the simple. Automated Deployment Guide for front-end Teams – Environment

Task mechanism

In a CI file, we can define a series of tasks, each of which must contain at least one executable statement

job1:
    script:
        - npm run build:job1
job2:
    script:
        - npm run build:job2
Copy the code

You can define all statements that the Runner environment can execute in script, and each task will be executed in the order defined. Note that the following keywords cannot be used as task names

Building scenarios

The stages keyword is used to define build scenarios and can be referenced by build tasks to define their own build scenarios. The order in which stages is defined also determines the order in which tasks are executed. The following is an example of a basic scenario

stages:
    - test
    - build
    - publish
Copy the code

1. Firstly, the construction scenario of all tasks istestAll tasks are executed in parallel
2. The build scenario is then performedbuildAll tasks of
3. Finally, the construction scenario is executedpublishAll tasks of
4. If any one of these tasks fails, the pipeline fails, and subsequent tasks are not executed

stagesCan not be defined, then the program will default totest build deployThree scenarios if a task does not specify its ownstage, then it will be used by defaulttest

Task section

Before_script and after_script are the keywords here, because they are similar to AOP, SO I like to call them task cuts. Before_script is executed before and after all tasks. All installations that can define dependent environments in this keyword

before_script:
    - npm install
    - echo 'Install successful'
Copy the code

After_script is executed after the task has been executed, so you can do some notifies here. Note that after_script should be run in a separate environment, so the execution stack does not have access to certain variable definitions and file caches in the environment. You are advised to perform actions such as deployment in the Publish or deploy link

after_script:
    - /data/bin/emitUsers.sh $CI_PROJECT_NAME $GITLAB_USER_EMAIL Notify all users to complete the build
Copy the code

CI_PROJECT_NAME and GITLAB_USER_EMAIL above refer to built-in variables of Runner program. For the types of built-in variables, see the following built-in variables of CI program

Custom build variables

CI programs allow you to add custom variables to the build process. Note that variables defined in CI files are stored in Git repositories, so key paths or program Settings should not be set in custom variables

You can define your custom variables using the variables keyword

variables:
    MY_DATA: 'This is test message'
Copy the code

Variables can also be defined separately in a task and can only be used in that task

job1:
    variables:
        BUILD_PATH: '/data/web/$CI_PROJECT_NAME'
    script:
        - echo $BUILD_PATH
        - echo $MY_DATA
Copy the code

Use the cache

For example, in a front-end project where we need to cache the node_modules folder, we can define the cache keyword as follows. The PATHS keyword is an array of cached objects

cache:
    paths:
        - node_modules/
Copy the code

The key attribute in the cache can be used to define the function of the cache. If this policy is not set, all tasks that are all branches by default can use this policy

cache:
    key: $CI_JOB_NAME Different tasks on different branches use this cache
    key: $CI_COMMIT_REF_NAME Use the same cache for the same branch
    key: $CI_JOB_STAGE-$CI_COMMIT_REF_NAME Allow universal caching for each task on each branch
    paths:
        - node_modules/
Copy the code

There are also policy Settings in the cache, which can define the download push rules to be cached in each task. If set properly, this will greatly speed up your build task

Using a Docker

The image keyword allows the current CI program to run based on a Docker image. Of course, the premise is that the tags specified by your task must be Github Runner registered in the form of Docker. The CI program will search for the image locally by default, and if it does not exist, it will pull it from the Docker Hub

The services keyword defines other mirrors that need to depend on in a program running on images

The overall method of using Docker is similar to docker-compose

Mission mechanics explained in detail

job_name:
  # List of scripts or commands to run
  script:
    - npm install
    - npm run lint
  # pipelines phase
  stage: test
  # which branch only
  only:
    - master
  # except which branch
  except:
    - develop
  # specify which runner applies to the job
  tags:
    - fe-vue
  # Fault tolerance
  allow_failure: true
Copy the code

script

Used to define the shell script that needs to be executed in a task

script: "npm install"

Multiple sets of scripts are also possible
script:
	- npm install
    - npm run lint
    - npm run build
Copy the code

image && services

Works the same as external keywords, but only on the current task

stage

Defines the working scenario for the current task, which is usually defined in the Stages keyword. You can also use the default scenario, which is test by default

variables

Variables defined in the current task will overwrite global variables that have been declared. If this keyword is set, global variables set in YAML files in the current task will not take effect

only && except

When will these two keywords define tasks to be created

1. onlyDefines the branch or label on which the task needs to be executed
2. exceptDefines the branch or label on which the task will not execute

Here are some rules for using these two parameters:

1. If both exist in a task statement, the required references will be filtered using the intersection of the two
2. Both allow the use of re

tags

Specify the runners to which the current task applies

when

Specify when the current task will be executed. Support the following four keywords

1. on_successThe current task is executed only if all jobs executed in the previous scenario succeed, which is the default value, meaning that if any task in the pipeline fails, the entire pipeline will fail
2. on_failureExecute only if at least one of the tasks performed in the previous scenario failed
3. alwaysAlways perform
4. manualPerformed manually

artifacts

Specifies the artifact cache for the current task, which can be used to pass artifacts between tasks and also contains multiple personalization Settings. Refer to the original documentation

CI program built-in variables

Custom variables have a priority policy. If you set a variable with the same name, its value can override the built-in variables of CI. The priority of the variables is as follows, from high to low

1. Secret variables(Private variable, can be inGitlab, suitable for all assembly lines)
2. YAML-defined job-level variables (CILocal variables defined in files, such as those defined in tasks)
3. YAML-defined global variables (CIGlobal variables defined in the file)
4. Deployment variables(Item variable,The document)
5. Predefined variables(Built-in variable)

Some of the built-in variables of Gitlab CI are provided here, currently based on Gitlab version 9.0 and above. If you find some variables do not exist or do not meet expectations, you can visit the original document to see the current name and meaning

When using variables in multiple environments, you need to distinguish between slightly different ways of using variables

1. bash/sh >>> $variable
2. windows batch >>> %variable%
3. PowerShell >>> $env:variable

You can also use the export keyword to print out all the variables. Note that this keyword also prints out all the private variables defined in the task

job:
    script:
        - export
Copy the code

An example of built-in variable printing is shown below

export CI_JOB_ID = '50'
export CI_COMMIT_SHA = '1ecfd275763eff1d6b4844ea3168962458c9f27a'
export CI_COMMIT_SHORT_SHA = '1ecfd275'
export CI_COMMIT_REF_NAME = 'master'
export CI_REPOSITORY_URL = 'https://gitlab-ci-token:[email protected]/gitlab-org/gitlab-foss.git'
export CI_COMMIT_TAG = '1.0.0'
export CI_JOB_NAME = 'spec:other'
export CI_JOB_STAGE = 'test'
export CI_JOB_MANUAL = 'true'
export CI_JOB_TRIGGERED = 'true'
export CI_JOB_TOKEN = 'abcde-1234ABCD5678ef'
export CI_PIPELINE_ID = '1000'
export CI_PIPELINE_IID = '10'
export CI_PAGES_DOMAIN = 'gitlab.io'
export CI_PAGES_URL = 'https://gitlab-org.gitlab.io/gitlab-foss'
export CI_PROJECT_ID = '34'
export CI_PROJECT_DIR = '/builds/gitlab-org/gitlab-foss'
export CI_PROJECT_NAME = 'gitlab-foss'
export CI_PROJECT_TITLE = 'GitLab FOSS'
export CI_PROJECT_NAMESPACE = 'gitlab-org'
export CI_PROJECT_PATH = 'gitlab-org/gitlab-foss'
export CI_PROJECT_URL = 'https://example.com/gitlab-org/gitlab-foss'
export CI_REGISTRY = 'registry.example.com'
export CI_REGISTRY_IMAGE = 'registry.example.com/gitlab-org/gitlab-foss'
export CI_REGISTRY_USER = 'gitlab-ci-token'
export CI_REGISTRY_PASSWORD = 'longalfanumstring'
export CI_RUNNER_ID = '10'
export CI_RUNNER_DESCRIPTION = 'my runner'
export CI_RUNNER_TAGS = 'docker, linux'
export CI_SERVER = 'yes'
export CI_SERVER_URL = 'https://example.com'
export CI_SERVER_HOST = 'example.com'
export CI_SERVER_PORT = '443'
export CI_SERVER_PROTOCOL = 'https'
export CI_SERVER_NAME = 'GitLab'
export CI_SERVER_REVISION = '70606bf'
export CI_SERVER_VERSION = '8.9.0'
export CI_SERVER_VERSION_MAJOR = '8'
export CI_SERVER_VERSION_MINOR = '9'
export CI_SERVER_VERSION_PATCH = '0'
export GITLAB_USER_EMAIL = '[email protected]'
export GITLAB_USER_ID = '42'
Copy the code

conclusion

Referring to the configuration file Settings above is enough to complete most CI and CD tasks, but it is not enough in the level of personalized Settings. In addition, the text description is a little stiff, and basically refers to the translation content of the original document, which is slightly difficult to learn

Next article will bring you the CI,CD deployment tutorial, more details of the strategy and application, please pay attention