gitlab-ci详细说明
文章目录
- 概念
- Pipeline
- Stages
- Jobs
- job分组
- variables
- 自定义变量
- 预定义变量
- 使用变量
- 关键词
- 全局关键词
- before_script
- after_script
- include
- Stage关键词
- Job关键词
- script
- image
- artifacts
- tags
- cache
- stage
- when
- only/except
- dependencies
- extends
- trigger
- rules
- allow_failure
- coverage
- pages
- release
- resource_group
- retry
- timeout
- 参考
- gitlabci变量
概念
从 Gitlab 8.0 开始,Gitlab CI 就已经集成在 Gitlab 中,我们只要在项目中添加一个.gitlab-ci.yml
文件,然后添加一个Runner
,即可进行持续集成。
Pipeline
一次 Pipeline 其实相当于一次构建任务,里面可以包含很多个流程,如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。任何提交或者 Merge Request
的合并都可以触发 Pipeline 构建。
Stages
Stages 表示一个构建阶段,也就是上面提到的一个流程。我们可以在一次 Pipeline 中定义多个 Stages,这些 Stages 会有以下特点:
- 所有 Stages 会按照顺序运行,即当一个 Stage 完成后,下一个 Stage 才会开始
- 只有当所有 Stages 完成后,该构建任务 (Pipeline) 才会成功
- 如果任何一个 Stage 失败,那么后面的 Stages 不会执行,该构建任务 (Pipeline) 失败
Jobs
Jobs 表示构建工作,表示某个 Stage 里面执行的工作。我们可以在 Stages 里面定义多个 Jobs,这些 Jobs 会有以下特点:
- 相同 Stage 中的 Jobs 会并行执行
- 相同 Stage 中的 Jobs 都执行成功时,该 Stage 才会成功
- 如果任何一个 Job 失败,那么该 Stage 失败,即该构建任务 (Pipeline) 失败
job分组
可以把job分组,通过 以下方式,job名称为build ruby,有3步。
build ruby 1/3:stage: buildscript:- echo "ruby1"build ruby 2/3:stage: buildscript:- echo "ruby2"build ruby 3/3:stage: buildscript:- echo "ruby3"
variables
变量包括自定义变量和CI/CD预定义的变量。
参考:https://docs.gitlab.com/ee/ci/variables/#variables
自定义变量
自定义变量可以通过以下语句定义:
variables:TEST: "HELLO WORLD"
预定义变量
There are also Kubernetes-specific deployment variables.
Variable | GitLab | Runner | Description |
---|---|---|---|
CHAT_CHANNEL
|
10.6 | all | The Source chat channel that triggered the ChatOps command. |
CHAT_INPUT
|
10.6 | all | The additional arguments passed with the ChatOps command. |
CI
|
all | 0.4 |
Available for all jobs executed in CI/CD. true when available.
|
CI_API_V4_URL
|
11.7 | all | The GitLab API v4 root URL. |
CI_BUILDS_DIR
|
all | 11.10 | The top-level directory where builds are executed. |
CI_COMMIT_BEFORE_SHA
|
11.2 | all |
The previous latest commit present on a branch. Is always 0000000000000000000000000000000000000000 in pipelines for merge requests.
|
CI_COMMIT_BRANCH
|
12.6 | 0.5 | The commit branch name. Available in branch pipelines, including pipelines for the default branch. Not available in merge request pipelines or tag pipelines. |
CI_COMMIT_DESCRIPTION
|
10.8 | all | The description of the commit. If the title is shorter than 100 characters, the message without the first line. |
CI_COMMIT_MESSAGE
|
10.8 | all | 提交message。 |
CI_COMMIT_REF_NAME
|
9.0 | all | branch or tag名称 |
CI_COMMIT_REF_PROTECTED
|
11.11 | all |
true if the job is running for a protected reference.
|
CI_COMMIT_REF_SLUG
|
9.0 | all |
CI_COMMIT_REF_NAME in lowercase, shortened to 63 bytes, and with everything except 0-9 and a-z replaced with - . No leading / trailing - . Use in URLs, host names and domain names.
|
CI_COMMIT_SHA
|
9.0 | all | 提交version |
CI_COMMIT_SHORT_SHA
|
11.7 | all |
CI_COMMIT_SHA 前8字符
|
CI_COMMIT_TAG
|
9.0 | 0.5 | The commit tag name. Available only in pipelines for tags. |
CI_COMMIT_TIMESTAMP
|
13.4 | all | The timestamp of the commit in the ISO 8601 format. |
CI_COMMIT_TITLE
|
10.8 | all | The title of the commit. The full first line of the message. |
CI_CONCURRENT_ID
|
all | 11.10 | The unique ID of build execution in a single executor. |
CI_CONCURRENT_PROJECT_ID
|
all | 11.10 | The unique ID of build execution in a single executor and project. |
CI_CONFIG_PATH
|
9.4 | 0.5 |
The path to the CI/CD configuration file. Defaults to .gitlab-ci.yml .
|
CI_DEBUG_TRACE
|
all | 1.7 |
true if debug logging (tracing) is enabled.
|
CI_DEFAULT_BRANCH
|
12.4 | all | The name of the project’s default branch. |
CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX
|
13.7 | all | The image prefix for pulling images through the Dependency Proxy. |
CI_DEPENDENCY_PROXY_PASSWORD
|
13.7 | all | The password to pull images through the Dependency Proxy. |
CI_DEPENDENCY_PROXY_SERVER
|
13.7 | all |
The server for logging in to the Dependency Proxy. This is equivalent to $CI_SERVER_HOST:$CI_SERVER_PORT .
|
CI_DEPENDENCY_PROXY_USER
|
13.7 | all | The username to pull images through the Dependency Proxy. |
CI_DEPLOY_FREEZE
|
13.2 | all |
Only available if the pipeline runs during a deploy freeze window. true when available.
|
CI_DEPLOY_PASSWORD
|
10.8 | all | The authentication password of the GitLab Deploy Token, if the project has one. |
CI_DEPLOY_USER
|
10.8 | all | The authentication username of the GitLab Deploy Token, if the project has one. |
CI_DISPOSABLE_ENVIRONMENT
|
all | 10.1 |
Only available if the job is executed in a disposable environment (something that is created only for this job and disposed of/destroyed after the execution - all executors except shell and ssh ). true when available.
|
CI_ENVIRONMENT_NAME
|
8.15 | all |
The name of the environment for this job. Available if environment:name is set.
|
CI_ENVIRONMENT_SLUG
|
8.15 | all |
The simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, and so on. Available if environment:name is set.
|
CI_ENVIRONMENT_URL
|
9.3 | all |
The URL of the environment for this job. Available if environment:url is set.
|
CI_HAS_OPEN_REQUIREMENTS
|
13.1 | all |
Only available if the pipeline’s project has an open requirement. true when available.
|
CI_JOB_ID
|
9.0 | all | job id |
CI_JOB_IMAGE
|
12.9 | 12.9 | 运行job的容器的image |
CI_JOB_JWT
|
12.10 | all | A RS256 JSON web token to authenticate with third party systems that support JWT authentication, for example HashiCorp’s Vault. |
CI_JOB_MANUAL
|
8.12 | all | job是否是人工执行的 |
CI_JOB_NAME
|
8.12 | all | job名称 |
CI_JOB_STAGE
|
9.0 | 0.5 | The name of the job’s stage. |
CI_JOB_STATUS
|
all | 13.5 |
The status of the job as each runner stage is executed. Use with after_script . Can be success , failed , or canceled .
|
CI_JOB_TOKEN
|
9.0 | 1.2 | A token to authenticate with certain API endpoints. The token is valid as long as the job is running. |
CI_JOB_URL
|
11.1 | 0.5 | The job details URL. |
CI_JOB_STARTED_AT
|
13.10 | all | The UTC datetime when a job started, in ISO 8601 format. |
CI_KUBERNETES_ACTIVE
|
13.0 | all |
Only available if the pipeline has a Kubernetes cluster available for deployments. true when available.
|
CI_NODE_INDEX
|
11.5 | all |
The index of the job in the job set. Only available if the job uses parallel .
|
CI_NODE_TOTAL
|
11.5 | all |
The total number of instances of this job running in parallel. Set to 1 if the job does not use parallel .
|
CI_OPEN_MERGE_REQUESTS
|
13.8 | all |
A comma-separated list of up to four merge requests that use the current branch and project as the merge request source. Only available in branch and merge request pipelines if the branch has an associated merge request. For example, gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11 .
|
CI_PAGES_DOMAIN
|
11.8 | all | The configured domain that hosts GitLab Pages. |
CI_PAGES_URL
|
11.8 | all |
The URL for a GitLab Pages site. Always a subdomain of CI_PAGES_DOMAIN .
|
CI_PIPELINE_ID
|
8.10 | all | 流水线ID,gitlab实例内唯一 |
CI_PIPELINE_IID
|
11.0 | all | 流水线ID,项目内唯一 |
CI_PIPELINE_SOURCE
|
10.0 | all |
How the pipeline was triggered. Can be push , web , schedule , api , external , chat , webide , merge_request_event , external_pull_request_event , parent_pipeline , trigger , or pipeline .
|
CI_PIPELINE_TRIGGERED
|
all | all |
true if the job was triggered.
|
CI_PIPELINE_URL
|
11.1 | 0.5 | The URL for the pipeline details. |
CI_PIPELINE_CREATED_AT
|
13.10 | all | The UTC datetime when the pipeline was created, in ISO 8601 format. |
CI_PROJECT_CONFIG_PATH
|
13.8 | all | (Deprecated) The CI configuration path for the project. Deprecated in GitLab 13.10. Removal planned for GitLab 14.0. |
CI_PROJECT_DIR
|
all | all |
The full path the repository is cloned to, and where the job runs from. If the GitLab Runner builds_dir parameter is set, this variable is set relative to the value of builds_dir . For more information, see the Advanced GitLab Runner configuration.
|
CI_PROJECT_ID
|
all | all | The ID of the current project. This ID is unique across all projects on the GitLab instance. |
CI_PROJECT_NAME
|
8.10 | 0.5 |
The name of the directory for the project. For example if the project URL is gitlab.example.com/group-name/project-1 , CI_PROJECT_NAME is project-1 .
|
CI_PROJECT_NAMESPACE
|
8.10 | 0.5 | The project namespace (username or group name) of the job. |
CI_PROJECT_PATH_SLUG
|
9.3 | all |
$CI_PROJECT_PATH in lowercase with characters that are not a-z or 0-9 replaced with - . Use in URLs and domain names.
|
CI_PROJECT_PATH
|
8.10 | 0.5 | The project namespace with the project name included. |
CI_PROJECT_REPOSITORY_LANGUAGES
|
12.3 | all |
A comma-separated, lowercase list of the languages used in the repository. For example ruby,javascript,html,css .
|
CI_PROJECT_ROOT_NAMESPACE
|
13.2 | 0.5 |
The root project namespace (username or group name) of the job. For example, if CI_PROJECT_NAMESPACE is root-group/child-group/grandchild-group , CI_PROJECT_ROOT_NAMESPACE is root-group .
|
CI_PROJECT_TITLE
|
12.4 | all | The human-readable project name as displayed in the GitLab web interface. |
CI_PROJECT_URL
|
8.10 | 0.5 | The HTTP(S) address of the project. |
CI_PROJECT_VISIBILITY
|
10.3 | all |
The project visibility. Can be internal , private , or public .
|
CI_REGISTRY_IMAGE
|
8.10 | 0.5 | The address of the project’s Container Registry. Only available if the Container Registry is enabled for the project. |
CI_REGISTRY_PASSWORD
|
9.0 | all | The password to push containers to the project’s GitLab Container Registry. Only available if the Container Registry is enabled for the project. |
CI_REGISTRY_USER
|
9.0 | all | The username to push containers to the project’s GitLab Container Registry. Only available if the Container Registry is enabled for the project. |
CI_REGISTRY
|
8.10 | 0.5 |
The address of the GitLab Container Registry. Only available if the Container Registry is enabled for the project. This variable includes a :port value if one is specified in the registry configuration.
|
CI_REPOSITORY_URL
|
9.0 | all | The URL to clone the Git repository. |
CI_RUNNER_DESCRIPTION
|
8.10 | 0.5 | The description of the runner. |
CI_RUNNER_EXECUTABLE_ARCH
|
all | 10.6 | The OS/architecture of the GitLab Runner executable. Might not be the same as the environment of the executor. |
CI_RUNNER_ID
|
8.10 | 0.5 | The unique ID of the runner being used. |
CI_RUNNER_REVISION
|
all | 10.6 | The revision of the runner running the job. |
CI_RUNNER_SHORT_TOKEN
|
all | 12.3 | First eight characters of the runner’s token used to authenticate new job requests. Used as the runner’s unique ID. |
CI_RUNNER_TAGS
|
8.10 | 0.5 | A comma-separated list of the runner tags. |
CI_RUNNER_VERSION
|
all | 10.6 | The version of the GitLab Runner running the job. |
CI_SERVER_HOST
|
12.1 | all |
The host of the GitLab instance URL, without protocol or port. For example gitlab.example.com .
|
CI_SERVER_NAME
|
all | all | The name of CI/CD server that coordinates jobs. |
CI_SERVER_PORT
|
12.8 | all |
The port of the GitLab instance URL, without host or protocol. For example 8080 .
|
CI_SERVER_PROTOCOL
|
12.8 | all |
The protocol of the GitLab instance URL, without host or port. For example https .
|
CI_SERVER_REVISION
|
all | all | GitLab revision that schedules jobs. |
CI_SERVER_URL
|
12.7 | all |
The base URL of the GitLab instance, including protocol and port. For example https://gitlab.example.com:8080 .
|
CI_SERVER_VERSION_MAJOR
|
11.4 | all |
The major version of the GitLab instance. For example, if the GitLab version is 13.6.1 , the CI_SERVER_VERSION_MAJOR is 13 .
|
CI_SERVER_VERSION_MINOR
|
11.4 | all |
The minor version of the GitLab instance. For example, if the GitLab version is 13.6.1 , the CI_SERVER_VERSION_MINOR is 6 .
|
CI_SERVER_VERSION_PATCH
|
11.4 | all |
The patch version of the GitLab instance. For example, if the GitLab version is 13.6.1 , the CI_SERVER_VERSION_PATCH is 1 .
|
CI_SERVER_VERSION
|
all | all | The full version of the GitLab instance. |
CI_SERVER
|
all | all |
Available for all jobs executed in CI/CD. yes when available.
|
CI_SHARED_ENVIRONMENT
|
all | 10.1 |
Only available if the job is executed in a shared environment (something that is persisted across CI/CD invocations, like the shell or ssh executor). true when available.
|
GITLAB_CI
|
all | all |
Available for all jobs executed in CI/CD. true when available.
|
GITLAB_FEATURES
|
10.6 | all | The comma-separated list of licensed features available for the GitLab instance and license. |
GITLAB_USER_EMAIL
|
8.12 | all | The email of the user who started the job. |
GITLAB_USER_ID
|
8.12 | all | The ID of the user who started the job. |
GITLAB_USER_LOGIN
|
10.0 | all | The username of the user who started the job. |
GITLAB_USER_NAME
|
10.0 | all | The name of the user who started the job. |
TRIGGER_PAYLOAD
|
13.9 | all | The webhook payload. Only available when a pipeline is triggered with a webhook. |
使用变量
Shell | Usage |
---|---|
bash/sh |
$variable ,${variable}
|
PowerShell |
$env:variable (primary) or $variable
|
Windows Batch |
%variable% , or !variable! for delayed expansion, which can be used for variables that contain white spaces or newlines.
|
变量可以通过依赖job 来继承。
关键词
全局关键词
before_script
before_script 关键词是用于在每个任务之前执行的脚本,但是会在artifacts恢复之后执行。你可以这样定义一个全局的before_script,
default:before_script:- echo "Execute this script in all jobs that don't already have a before_script section."
也可以在一个任务中中单独定义
job:before_script:- echo "Execute this script instead of the global before_script."script:- echo "This script executes after the job's `before_script`"
任务中的
before_script
会覆盖全局的before_script
after_script
after_script与before_script类似,用于定义多行脚本,会在任务执行完成后执行,即使任务失败也会被执行。如果任务被取消或者超时,after_script就不会被执行了,可以定义全局的,也可以定义局部的
default:after_script:- echo "Execute this script in all jobs that don't already have an after_script section."job1:script:- echo "This script executes first. When it completes, the global after_script executes."
include
使用include
可以导入一个或多个额外的yaml
文件到CI/CD配置里,这就可以将一个很长的流水线,分隔出来。使用include来引入。
也可以将几个流水线中相同的配置,提取出来,公用。引入的文件扩展名 必须是.yaml或者.yml两种,其他的不行。
include 关键词下,有四个可选性:
- local, 引入一个当前项目的文件
- file, 引入一个不同项目的文件
- remote, 引入一个公网文件,
- template, 引入一个由GitLab提供的模板
include:- local: '/templates/.gitlab-ci-template.yml'
---
include:- project: 'my-group/my-project' #另外一个项目file: '/templates/.gitlab-ci-template.yml'ref: master #master分支
---
include:- remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'
Stage关键词
Job关键词
script
任务要执行的shell脚本内容,内容会被runner执行,在这里,你不需要使用git clone …克隆当前的项目,来进行操作,因为在流水线中,每一个的job的执行都会将项目下载,恢复缓存这些流程,不需要你再使用脚本恢复。你只需要在这里写你的项目安装,编译执行,如
npm install 另外值得一提的是,脚本的工作目录就是当前项目的根目录,所有可以就像在本地开发一样。此外script可以是单行或者多行
单行脚本:
job:script: npm install
多行脚本:
job:script:- npm config set sass_binary_site https://npm.taobao.org/mirrors/node-sass/- npm install --registry=http://registry.npm.taobao.org
***script***是一个job的必填内容,不可或缺。一个job最少有二个属性,一个是 job name, 任务名称, 一个就是script。
image
指定一个基础Docker镜像作为基础运行环境,经常用到的镜像有node, nginx ,docker
job:image: node:latestscript: npm install
image的作用就是给当前任务或者当前流水线设置一个基础环境,有可能是nodejs,也有可能是java, go, php,可以设置当前流水线的,也可以设置当前任务的。
artifacts
制品,一个成品,作用是将流水线过程中的一些文件,文件夹,打包压缩,提供一个外链供人下载,另外还能在后续的job中缓存。
比如我们构建一个前端项目后将dist目录做成一个压缩包,
build:script:- npm run buildartifacts:paths:- dist/
后面的任务可以使用生成的制品。
paths 是用来指定将哪些文件,目录放入制品中, 也可以使用exclude关键词,将那些目录,文件排除,支持正则表达式。
此外还有以下几个属性:
- paths :文件路径
- exclude: 排除的文件
- name :制品名称
- expose_as: 在UI页面导出的名称
- untracked :布尔类型,是否将git忽略的文件加到制品中
- when :何时上传制品,可选值:on_success;on_failure;always
- expire_in: 过期时间默认30天
- reports: 收集测试报告
build:script:- npm run buildartifacts:paths:- dist/exclude:- binaries/**/*.oexpose_as: 'artifact 1'name: "$CI_COMMIT_REF_NAME"untracked: falseexpire_in: 2 hrs 20 minwhen: on_failure
tags
tags 关键词是用于指定Runner。tags的取值范围是在该项目可见的runner tags
中,可以在Setting =>CI/CD => Runner 中查看的到。不设置则默认使用公有Runner去执行流水线。每个任务可以指定一个Runner,可以指定多个标签,但runner却只能一个。以一个为准。tags是在注册Runner时配置的,后续也可以更改。
install:tags:- hello-vue- dockerscript:- npm config set sass_binary_site https://npm.taobao.org/mirrors/node-sass/- npm install --registry=http://registry.npm.taobao.org
cache
缓存是将当前工作环境目录中的一些文件,一些文件夹存储起来,用于在各个任务初始化的时候恢复。避免多个下载同样的包,能够大大优化流水线效率。在前端项目中,我们经常把node_modules
缓存起来,这样一条流水线都可以使用这些下载好的包。在java项目中经常把maven下载的包缓存起来。以备后用
cache下的参数有
- paths:当前工作环境下的目录
- key:存储的key,key不变不会重新生成缓存,
- prefix:使用一些文件制作成文件hash值,当做key的一部分,
- untracked :是否缓存git忽略的文件
- when :定义何时存储缓存,值 on_success;on_failure;always
- policy:缓存是否要在job完成后重新上传
缓存可以设置流水线全局,也可以在job中设置
cache:key: hello-vue-cachepaths:- node_modules#####
cache:key:files:- Gemfile.lock- package.jsonpaths:- vendor/ruby- node_modules
stage
stage 是阶段的意思,用于归档一部分的job,按照定义的stage顺序来执行。默认的stage有build,test,deploy, 此外还有两个特殊的.pre 和 .post。以下执行顺序: job_1,job_0。
stages:- build- test- deployjob_0:stage: testscript: echo 'tets'job_1:stage: buildscript: echo 'build'
when
when关键字是实现在发生故障或尽管发生故障时仍能运行的作业。比如你要在任务失败后需要触发一个job,
或者你需要手动执行任务,或者当你一个任务执行成功后,执行另一个任务.
- on_success 所有任务执行成功后
- on_failure 当至少一个任务失败后
- always 执行作业,而不考虑作业在早期阶段的状态。
- manual 手动执行任务
- delayed 延迟执行任务
- never
在rules中不排除执行的任务
在workflow:rules不允许的流水线
only/except
only/except 是规定当前job的可见状态,一个项目有很多分支,tag,我们的流水线,为了对特定的分支,特定的tag执行不同的job,这里就要使用only和except
在任务上加上这一段代码,就表明当前任务只有在master分支可以运行
only:- master
也可以根据当前的代码变动是合并,还是推送,还是使用API来触发的。如果一个任务没有only属性,那默认就是
only: ['branches', 'tags'] 操作分支或者tags都会触发流水线。
dependencies
dependencies关键词是定义特定的job运行规则。默认artifacts
是从当前阶段产生,在后续的阶段都会被下载,但我们可以使用dependencies
关键词来控制artifacts
从哪里下载。
build:osx:stage: buildscript: make build:osxartifacts:paths:- binaries/build:linux:stage: buildscript: make build:linuxartifacts:paths:- binaries/test:osx:stage: testscript: make test:osxdependencies:- build:osx #依赖test:linux:stage: testscript: make test:linuxdependencies:- build:linux #依赖deploy:stage: deployscript: make deploy
任务test:osx 依赖build:osx。任务test:linux 依赖 build:linux。这样配置以后 任务test:linux 就不用等任务build:osx 执行完成在执行了,只需要等待任务build:linux完成
extends
这个关键词可以使一个任务继承另一个任务。
.tests:script: rake teststage: testonly:refs:- branchesrspec:extends: .testsscript: rake rspeconly:variables:- $RSPEC
任务rspec 继承了.tests任务,在流水线中.tests是一个隐藏的任务,在流水线中,以点(.) 开头的任务名,都是隐藏的任务。不会被执行。 被rspec 继承后,相同的key会以rspec为准,rspec没有的,而.tests有的,则合并到rspec中。
合并后的结果是:
rspec:script: rake rspecstage: testonly:refs:- branchesvariables:- $RSPEC
使用这一个手段,可以写一个模板,只要稍微改改就能后使用。非常适合大批量编写流水线。
trigger
trigger 是应对那些更加复杂的CI/CD流程,如多流水线,父子流水线。使用它可以定义一个下游的流水线,配置了trigger
的任务是不能跑脚本的,就是说不能定义script, before_script, 和 after_script.
#流水线执行完test任务后就会去执行my/deployment项目的流水线
rspec:stage: testscript: bundle exec rspecstaging:stage: deploytrigger: my/deployment
---
#配置下游流水线式也可以执行分支
rspec:stage: testscript: bundle exec rspecstaging:stage: deploytrigger:project: my/deploymentbranch: stablez
rules
rules
是用于规定任务的执行规则,使用一个表达式,来规范那些任务执行,那些任务不执行.还可以在任务成功,或者失败后,触发另一个任务。
docker build:script: docker build -t my-image:$CI_COMMIT_REF_SLUG .rules: #如果当前的分支是master分支则任务延迟3个小时执行,并且允许失败。- if: '$CI_COMMIT_BRANCH == "master"'when: delayedstart_in: '3 hours'allow_failure: true
rules
的下面可选属性
- if:使用if表达式 添加或移除一个任务, 类似
only:variables.
- changes:根据某些个文件是否改变来追加或移除一些任务。类似
only:changes.
- exists :根据是否存在特定文件来追加或移除一些任务
allow_failure
allow_failure是一个布尔类型, true或false, 默认为false,表示当前任务是否允许失败。如果一个任务设置了allow_failure: true
,并且这个任务报错了,那么它将会显示黄色警告。但有种情况任务失败了也会停止的, 那就是任务设置了when: manual
,即手动操作的任务。手动启动的任务,报错了就会停止,不会继续执行后续任务,除非在rule设置报错的处理逻辑。
coverage
coverage
是用于获取项目的代码覆盖率,这个配置项的值只能是一个正则表达式,官方有提供一些,在CI/CD的General pipelines里
覆盖率可以添加到项目的readme上。
pages
pages是一项特殊的工作,用于将静态内容上传到GitLab,可用于为您的网站提供服务,其实就是可以托管你的网站。它具有特殊的语法,因此必须满足以下两个要求:
- 任何静态内容都必须放在public/目录下。
- 制品artifacts必须是目录public/,就是编译后的文件必须存放在public中
下面的示例将所有文件从项目的根目录移至public/
目录。这里必须先创建一个.public
目录,防止根目录下已经存在public
了,导致循环复制。
pages:stage: deployscript:- mkdir .public- cp -r * .public- mv .public publicartifacts:paths:- publiconly:- master
release
release
关键词是用于创建一个release
,即创建一个发布,可以配置这些内容
tag_name
: tag 名称description
: 描述name
:名称ref
:提交的hash值milestones
: 要关联的里程碑released_at
: 创建时间
resource_group
有时在环境中同时运行多个作业或流水线时可能会导致在部署过程中出错。为了避免这些错误,resource_group
可以使用该属性来确保运行程序不会同时运行某些任务。资源组的行为类似于其他编程语言中的信号灯。
当一个任务设置了resource_group
, 同一项目的不同管道之间任务的运行是互斥的。如果属于同一资源组的多个任务同时进入队列,则运行程序仅选择其中一个作业。其他作业将等到 resource_group释放。
deploy-to-production:script: deployresource_group: production
在这种情况下,两个deploy-to-production单独流水线中的两个作业永远无法同时运行。最后的结果及时你可以确保永远不会在生产环境中发生并发部署。
您可以为每个环境定义多个资源组。例如,当部署到物理设备时,您可能有多个物理设备。可以将每个设备部署到,但是在任何给定时间每个设备只能部署一个。
resource_group值只能包含字母,数字,-, _, /, $, {, }, .,和空格。它不能以开头或结尾/。
retry
retry可以设置一个任务的重试次数,值的类型是数字 最大是2,如果设置2,就表明该任务最多可以执行3次,其中包括2次重试。对于网络不稳定的部署,非常有用。
test:script: rspecretry: 2
timeout
timeout是用于设置一个任务的超时时间
build:script: build.shtimeout: 3 hours 30 minutestest:script: rspectimeout: 3h 30m
参考
原文链接:https://blog.csdn.net/github_35631540/article/details/111029151
job keywords:https://docs.gitlab.com/ee/ci/yaml/#job-keywords
rules:https://docs.gitlab.com/ee/ci/yaml/#rules
https://docs.gitlab.com/11.11/ee/ci/yaml/README.html#when
变量:https://docs.gitlab.com/ee/ci/variables/README.html
yaml:http://192.168.1.X/help/ci/yaml/README.md
gitlabci变量
declare -x CI="true"
declare -x CI_BUILDS_DIR="/builds"
declare -x CI_BUILD_BEFORE_SHA="fc8c91ed7cb8f5eefe540786d48f9babd0b48155"
declare -x CI_BUILD_ID="49"
declare -x CI_BUILD_NAME="mvn_build_job"
declare -x CI_BUILD_REF="e880f7c22eca83ac59eb263af097758a7a7f4f4a"
declare -x CI_BUILD_REF_NAME="master"
declare -x CI_BUILD_REF_SLUG="master"
declare -x CI_BUILD_STAGE="package"
declare -x CI_BUILD_TOKEN="xxxxxxxxxxxxxxxxxxxx"
declare -x CI_COMMIT_DESCRIPTION=""
declare -x CI_COMMIT_MESSAGE="更新 .gitlab-ci.yml"
declare -x CI_COMMIT_REF_NAME="master"
declare -x CI_COMMIT_REF_SLUG="master"
declare -x CI_COMMIT_SHA="e880f7c22eca83ac59eb263af097758a7a7f4f4a"
declare -x CI_COMMIT_TITLE="更新 .gitlab-ci.yml"
declare -x CI_CONCURRENT_ID="1"
declare -x CI_CONCURRENT_PROJECT_ID="1"
declare -x CI_CONFIG_PATH=".gitlab-ci.yml"
declare -x CI_DISPOSABLE_ENVIRONMENT="true"
declare -x CI_JOB_ID="49"
declare -x CI_JOB_IMAGE="XXXXX/maven:3.6.3-openjdk-8"
declare -x CI_JOB_NAME="mvn_build_job"
declare -x CI_JOB_STAGE="package"
declare -x CI_JOB_STATUS="running"
declare -x CI_JOB_TOKEN="xxxxxxxxxxxxxxxxxxxx"
declare -x CI_JOB_URL="http://xxxxx/base/demo-sample/-/jobs/49"
declare -x CI_PIPELINE_ID="22"
declare -x CI_PIPELINE_IID="11"
declare -x CI_PIPELINE_SOURCE="push"
declare -x CI_PIPELINE_URL="http://xxxxx/base/demo-sample/pipelines/22"
declare -x CI_PROJECT_DIR="/builds/base/demo-sample"
declare -x CI_PROJECT_ID="226"
declare -x CI_PROJECT_NAME="demo-sample"
declare -x CI_PROJECT_NAMESPACE="base"
declare -x CI_PROJECT_PATH="base/demo-sample"
declare -x CI_PROJECT_PATH_SLUG="base-demo-sample"
declare -x CI_PROJECT_URL="http://xxxxx/base/demo-sample"
declare -x CI_PROJECT_VISIBILITY="private"
declare -x CI_REGISTRY_PASSWORD="xxxxxxxxxxxxxxxxxxxx"
declare -x CI_REGISTRY_USER="gitlab-ci-token"
declare -x CI_REPOSITORY_URL="http://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@xxxxx/base/demo-sample.git"
declare -x CI_RUNNER_DESCRIPTION="gitlab-runner-gitlab-runner-79fdddc45c-tznlg"
declare -x CI_RUNNER_EXECUTABLE_ARCH="linux/amd64"
declare -x CI_RUNNER_ID="4"
declare -x CI_RUNNER_REVISION="54944146"
declare -x CI_RUNNER_SHORT_TOKEN="32d85b65"
declare -x CI_RUNNER_TAGS=""
declare -x CI_RUNNER_VERSION="13.10.0"
declare -x CI_SERVER="yes"
declare -x CI_SERVER_NAME="GitLab"
declare -x CI_SERVER_REVISION="63daf37"
declare -x CI_SERVER_VERSION="11.1.4"
declare -x DOCKER_TAG="1.0.0-RELEASE"
declare -x FF_CMD_DISABLE_DELAYED_ERROR_LEVEL_EXPANSION="false"
declare -x FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR="false"
declare -x FF_ENABLE_BASH_EXIT_CODE_CHECK="false"
declare -x FF_GITLAB_REGISTRY_HELPER_IMAGE="false"
declare -x FF_NETWORK_PER_BUILD="false"
declare -x FF_RESET_HELPER_IMAGE_ENTRYPOINT="true"
declare -x FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL="false"
declare -x FF_SKIP_NOOP_BUILD_STAGES="true"
declare -x FF_USE_DIRECT_DOWNLOAD="true"
declare -x FF_USE_FASTZIP="false"
declare -x FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER="true"
declare -x FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY="true"
declare -x FF_USE_WINDOWS_LEGACY_PROCESS_STRATEGY="true"
declare -x GITLAB_CI="true"
declare -x GITLAB_FEATURES=""
declare -x GITLAB_USER_EMAIL="xxxx@jurxxxx.com.cn"
declare -x GITLAB_USER_ID="59"
declare -x GITLAB_USER_LOGIN="lixx.jurxxx"
declare -x GITLAB_USER_NAME="xxxx"
declare -x HOME="/root"
declare -x HOSTNAME="runner-32d85b65-project-226-concurrent-1f625l"
declare -x JAVA_HOME="/usr/local/openjdk-8"
declare -x JAVA_VERSION="8u275"
declare -x KUBERNETES_PORT="tcp://10.233.0.1:443"
declare -x KUBERNETES_PORT_443_TCP="tcp://10.233.0.1:443"
declare -x KUBERNETES_PORT_443_TCP_ADDR="10.233.0.1"
declare -x KUBERNETES_PORT_443_TCP_PORT="443"
declare -x KUBERNETES_PORT_443_TCP_PROTO="tcp"
declare -x KUBERNETES_SERVICE_HOST="10.233.0.1"
declare -x KUBERNETES_SERVICE_PORT="443"
declare -x KUBERNETES_SERVICE_PORT_HTTPS="443"
declare -x LANG="C.UTF-8"
declare -x MAVEN_CONFIG="/root/.m2"
declare -x MAVEN_HOME="/usr/share/maven"
declare -x MINIO_PORT="tcp://10.233.36.231:9000"
declare -x MINIO_PORT_9000_TCP="tcp://10.233.36.231:9000"
declare -x MINIO_PORT_9000_TCP_ADDR="10.233.36.231"
declare -x MINIO_PORT_9000_TCP_PORT="9000"
declare -x MINIO_PORT_9000_TCP_PROTO="tcp"
declare -x MINIO_SERVICE_HOST="10.233.36.231"
declare -x MINIO_SERVICE_PORT="9000"
declare -x MINIO_SERVICE_PORT_9000_TCP="9000"
declare -x OLDPWD="/"
declare -x PATH="/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
declare -x PWD="/builds/base/sample"
declare -x SHLVL="1"
gitlab-ci详细说明相关推荐
- 【GitLab】GitLab CI/CD 模型部署自动化超详细介绍
文章目录 一.GitLab 二.GitLab-CI/CD 2.1 gitlab-ci.yml 2.1.1 基础概念 2.1.2 创建 yml 文件 2.1.3 yml 文件中的关键字 2.2 GitL ...
- GitLab CI流水线配置文件.gitlab-ci.yml详解(三)
GitLab CI流水线配置文件.gitlab-ci.yml详解 - contents:: 目录 本文讲解在 :ref:GitLab的汉化与CI持续集成gitlab-runner的配置 <con ...
- 指定的网络文件夹目前是以其他用户名和密码进行映射的_使用 GitLab CI 与 Argo CD 进行 GitOps 实践
在现在的云原生世界里面 GitOps 不断的被提及,这种持续交付的模式越来越受到了大家的青睐,我们前面也有文章详细讲解了 GitOps 的相关概念,在网上也可以找到很多关于它的资源,但是关于 GitO ...
- GitLab CI/CD
GitLab CI/CD 是一个内置在GitLab中的工具,用于通过持续方法进行软件开发: Continuous Integration (CI) 持续集成 Continuous Delivery ...
- ci 数据库异常捕获_系统地捕获错误:如何通过4个步骤构建GitLab CI测试管道
ci 数据库异常捕获 by Joyz 通过乔伊斯 系统地捕获错误:如何通过4个步骤构建GitLab CI测试管道 (Catch bugs systematically: how to build a ...
- gitlable iphone_使用gitlab ci构建IOS包并发送通知消息到企业微信
在之前的文章中,我们介绍了使用gitlab ci构建Android包的方法.今天我们介绍使用gitlab ci如何构建IOS包,并且在打包成功或者失败时,如何将消息通知到企业微信. 如果对gitlab ...
- 带你深入了解 GitLab CI/CD 原理及流程
作者:狂乱的贵公子 cnblogs.com/cjsblog/p/12256843.html GitLab CI/CD 是一个内置在GitLab中的工具,用于通过持续方法进行软件开发: Continuo ...
- gitlab ci 自动化部署_lt;为什么准备使用GitLab做CICD流水线?/gt;
本文是<GitLabCI实践>教程基础部分内容,讲述为什么要使用GitLabCICD功能,点击上面图片获取免费公开课报名链接,欢迎报名学习! 传统的应用开发发布模式 开发团队在开发环境中完 ...
- winform 项目 发布后比本地运行慢_前端团队基于 GitLab CI/CD 的自动化构建、发布实践,快来学习吧...
在公司搭建内部 GitLab 平台后,前端活动项目从 SVN 迁移到 GitLab.本文介绍如何基于 GitLab CI/CD 实现自动化构建及发布. 在从 SVN 迁移到 GitLab 和接入 Gi ...
- 基于 GitLab CI 的前端工程CI/CD实践
CI/CD 是 Gitlab 提供的一整套持续集成.持续交付解决方案. 概念:「持续集成(Continuous Integration)」.「持续交付(Continuous Delivery)」和「持 ...
最新文章
- 算法系列15天速成——第十天 栈
- 【百度地图API】百度API卫星图使用方法和卫星图对比工具
- python开发微信小程序-Python实现微信小程序支付功能
- 三伏天到了,记得为数据中心降降温
- Luogu2495[SDOI2011]消耗战
- [计组]寄存器的基本含义
- C++ new和delete
- php 读取excel转数组中,thinkphp5使用PHPExcel读取excel csv到数组
- linux 进程状态 load,Linux - 系统指标 CPU load
- php navigator,微信小程序组件:navigator页面链接解读和分析
- linux分享二:Linux如何修改字符集
- 计算机操作系统慕课版(汤小丹)--第一章课后题
- 茫茫社招路,硕士毕业半年的抉择
- 用VMWARE安装Mac OSX Tiger 10.4.4 X86
- GitHub每月优秀热门项目推荐:2021年12月
- [Android O] [RK3399] -- Vendor Storage 功能探究
- 三秒让你学会公私网地址转换(NAT)
- LPC1768 IAP写入bin格式程序不能启动的解决办法
- 冬至计算(一千年冬至计算)
- [转]String 之 new String()和 intern()方法深入分析
热门文章
- 中国软件正版化的理想模型
- java 集合类 map/set/list/vector之间的关系
- 【Hibernate】Hibernate中查询表名、字段名以及字段类型等信息
- nyoj 寻找最大数
- Android中Messenger的使用
- mysql中utf8_general_cs和utf8_general_ci和utf8_bin的一点区
- linux下gcc升级
- 【技术贴】红警三卡||红警三卡在游戏开始界面卡在右上角小星星卡在美女界面卡在创建名字黑屏的解决方案...
- 50多个强大的jQuery插件应用实例
- SpringBoot 实战:如何从零开发 “淘宝”