GitLab CI/CD Pipeline Configuration Reference：三 [Parameter details: script before_script and after_script stage]

script

script is the only required keyword that a job needs. It's a shell script which is executed by the Runner. For example:

job:
  script: "bundle exec rspec"

YAML anchors (锚) for scripts are available.

YAML anchors for script

Introduced in GitLab 12.5.

You can use YAML anchors with scripts, which makes it possible to
include a predefined list of commands in multiple jobs.
For example:

.something: &something
- echo 'something'

job_name:
  script:
    - *something
    - echo 'this is the script'

YAML anchors for variables
YAML anchors can be used with variables, to easily repeat assignment of variables across multiple jobs. It can also enable more flexibility when a job requires a specific variables 
block that would otherwise override the global variables.

In the example below, we will override the GIT_STRATEGY variable without affecting the use of the SAMPLE_VARIABLE variable:
# global variables
variables: &global-variables
  SAMPLE_VARIABLE: sample_variable_value

# a job that needs to set the GIT_STRATEGY variable, yet depend on global variables
job_no_git_strategy:
  stage: cleanup
  variables:
    <<: *global-variables
    GIT_STRATEGY: none
  script: echo $SAMPLE_VARIABLE

Hide jobs

Introduced in GitLab 8.6 and GitLab Runner v1.1.1.

If you want to temporarily 'disable' a job, rather than commenting out all the
lines where the job is defined:
#hidden_job:
#  script:
#    - run test
you can instead start its name with a dot (.) and it won't be processed by
GitLab CI/CD. In the following example, .hidden_job will be ignored:
.hidden_job:
  script:
    - run test
Use this feature to ignore jobs, or use the
special YAML features and transform the hidden jobs
into templates.

Skip Pipeline
If your commit message contains [ci skip] or [skip ci], using any
capitalization, the commit will be created but the pipeline will be skipped.
Alternatively, one can pass the ci.skip Git push option
if using Git 2.10 or newer.

This parameter can also contain several commands using an array:

job:
  script:
    - uname -a
    - bundle exec rspec

NOTE: Note: Sometimes, script commands will need to be wrapped in single or double quotes. For example, commands that contain a colon (:) need to be wrapped in quotes so that the YAML parser knows to interpret the whole thing as a string rather than a "key: value" pair. Be careful when using special characters: :, {, }, [, ], ,, &, *, #, ?, |, -, <, >, =, !, %, @, `.

If any of the script commands return an exit code different from zero, the job will fail and further commands won't be executed. This behavior can be avoided by storing the exit code in a variable:

job:
  script:
    - false || exit_code=$?
    - if [ $exit_code -ne 0 ]; then echo "Previous command failed"; fi;

###

before_script and after_script

Introduced in GitLab 8.7 and requires GitLab Runner v1.2.

• before_script is used to define a command that should be run before each job, including deploy jobs, but after the restoration of any artifacts. This must be an array.

Scripts specified in before_script are concatenated with any scripts specified in the main script, and executed together in a single shell. （before_script 中定义的脚本与 main script中的脚本是在同一个shell中执行的）

• after_script is used to define the command that will be run after each job, including failed ones. This must be an array. （after_script 在 job失败后依然会执行，并且会单独启动一个shell）

Scripts specified in after_script are executed in a new shell, separate from any before_script or script scripts. As a result, they:  

• Have a current working directory set back to the default.
• Have no access to changes done by scripts defined in before_script or script, including:
  • Command aliases and variables exported in script scripts.
  • Changes outside of the working tree (depending on the Runner executor), like software installed by a before_script or script script.
• Have a separate timeout, which is hard coded to 5 minutes. See related issue for details.
• Don't affect the job's exit code. If the script section succeeds and the after_script times out or fails, the job will exit with code 0 (Job Succeeded). (after_script成功与否并不影响job的最终执行状态)

It's possible to overwrite a globally defined before_script or after_script if you set it per-job:

default:
  before_script:
    - global before script

job:
  before_script:
    - execute this instead of global before script
  script:
    - my command
  after_script:
    - execute this after my script

YAML anchors for before_script and after_script are available.  （使用锚定）

 

 ###

stage

stage is defined per-job and relies on stages which is defined globally. It allows to group jobs into different stages, and jobs of the same stage are executed in parallel (subject to certain conditions). For example:

stage 被定义到每个job中，并且依赖于被定义在全局的stages.stage允许我们通过不同的stage将jobs区分成不同的分组，拥有相同stage的job可以并行执行，下一阶段的stage对应的job需要上一阶段job全部执行成功才会继续执行.

stages:
  - build
  - test
  - deploy

job 0:
  stage: .pre
  script: make something useful before build stage

job 1:
  stage: build
  script: make build dependencies

job 2:
  stage: build
  script: make build artifacts

job 3:
  stage: test
  script: make test

job 4:
  stage: deploy
  script: make deploy

job 5:
  stage: .post
  script: make something useful at the end of pipeline

###

.pre and .post

Introduced in GitLab 12.4.

The following stages are available to every pipeline:

• .pre, which is guaranteed to always be the first stage in a pipeline.
• .post, which is guaranteed to always be the last stage in a pipeline.

User-defined stages are executed after .pre and before .post.

The order of .pre and .post can't be changed, even if defined out of order in .gitlab-ci.yml. For example, the following are equivalent configuration:

• Configured in order:

  stages:
    - .pre
    - a
    - b
    - .post

• Configured out of order:

  stages:
    - a
    - .pre
    - b
    - .post

• Not explicitly configured:

  stages:
    - a
    - b

NOTE: Note: A pipeline won't be created if it only contains jobs in .pre or .post stages.

Using your own Runners

#设置job的并行执行（*同时使用不同的Runners  *修改Runner的并行度）

When using your own Runners, GitLab Runner runs only one job at a time by default (see the concurrent flag in Runner global settings for more information).

Jobs will run on your own Runners in parallel only if:

• Run on different Runners.
• The Runner's concurrent setting has been changed.

## 如何修改 Runner的 concurrent — 修改 config.toml 配置文件

[root@worker01 ~]# docker exec -it gitlab-runner cat /etc/gitlab-runner/config.toml
concurrent = 1
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "opstest"
  url = "http://10.197.236.131:9800/"
  token = "F_b9oZ1Riijo_W4TqxfA"
  executor = "shell"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]

Advanced configuration

GitLab Runner configuration uses the TOML format.

The file to be edited can be found in:

    /etc/gitlab-runner/config.toml on *nix systems when GitLab Runner is executed as root (this is also path for service configuration)   ## root用户使用的config.toml
    ~/.gitlab-runner/config.toml on *nix systems when GitLab Runner is executed as non-root  ## 非root用户使用的config.toml
    ./config.toml on other systems  ## 其它

The global section

This defines global settings of GitLab Runner.
Setting        Description
concurrent     limits how many jobs globally can be run concurrently. The most upper limit of jobs using all defined runners. 0 does not mean unlimited
log_level      Log level (options: debug, info, warn, error, fatal, panic). Note that this setting has lower priority than level set by command line argument --debug, -l, or --log-level
log_format     Log format (options: runner, text, json). Note that this setting has lower priority than format set by command line argument --log-format The default value is runner.
check_interval     defines the interval length, in seconds, between new jobs check. The default value is 3; if set to 0 or lower, the default value will be used.
sentry_dsn     enable tracking of all system level errors to Sentry
listen_address     address (<host>:<port>) on which the Prometheus metrics HTTP server should be listening

Configuration example:

concurrent = 4
log_level = "warning"

log_format examples (truncated)

runner

Runtime platform                                    arch=amd64 os=darwin pid=37300 revision=HEAD version=development version
Starting multi-runner from /etc/gitlab-runner/config.toml...  builds=0
WARNING: Running in user-mode.
WARNING: Use sudo for system-mode:
WARNING: $ sudo gitlab-runner...

Configuration loaded                                builds=0
listen_address not defined, metrics & debug endpoints disabled  builds=0
[session_server].listen_address not defined, session endpoints disabled  builds=0

text

INFO[0000] Runtime platform                              arch=amd64 os=darwin pid=37773 revision=HEAD version="development version"
INFO[0000] Starting multi-runner from /etc/gitlab-runner/config.toml...  builds=0
WARN[0000] Running in user-mode.
WARN[0000] Use sudo for system-mode:
WARN[0000] $ sudo gitlab-runner...
INFO[0000]
INFO[0000] Configuration loaded                          builds=0
INFO[0000] listen_address not defined, metrics & debug endpoints disabled  builds=0
INFO[0000] [session_server].listen_address not defined, session endpoints disabled  builds=0

json

{"arch":"amd64","level":"info","msg":"Runtime platform","os":"darwin","pid":38229,"revision":"HEAD","time":"2020-06-05T15:57:35+02:00","version":"development version"}
{"builds":0,"level":"info","msg":"Starting multi-runner from /etc/gitlab-runner/config.toml...","time":"2020-06-05T15:57:35+02:00"}
{"level":"warning","msg":"Running in user-mode.","time":"2020-06-05T15:57:35+02:00"}
{"level":"warning","msg":"Use sudo for system-mode:","time":"2020-06-05T15:57:35+02:00"}
{"level":"warning","msg":"$ sudo gitlab-runner...","time":"2020-06-05T15:57:35+02:00"}
{"level":"info","msg":"","time":"2020-06-05T15:57:35+02:00"}
{"builds":0,"level":"info","msg":"Configuration loaded","time":"2020-06-05T15:57:35+02:00"}
{"builds":0,"level":"info","msg":"listen_address not defined, metrics \u0026 debug endpoints disabled","time":"2020-06-05T15:57:35+02:00"}
{"builds":0,"level":"info","msg":"[session_server].listen_address not defined, session endpoints disabled","time":"2020-06-05T15:57:35+02:00"}

 

参考链接：

• https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
• https://docs.gitlab.com/ee/ci/yaml/