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_scriptis 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_scriptis 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_scriptorscript, including:- Command aliases and variables exported in
scriptscripts. - Changes outside of the working tree (depending on the Runner executor), like software installed by a
before_scriptorscriptscript.
- Command aliases and variables exported in
- 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
scriptsection succeeds and theafter_scripttimes out or fails, the job will exit with code0(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
concurrentsetting 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 (: ) 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"}