文章目录

  • 概念
    • 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详细说明相关推荐

  1. 【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 ...

  2. GitLab CI流水线配置文件.gitlab-ci.yml详解(三)

    GitLab CI流水线配置文件.gitlab-ci.yml详解 - contents:: 目录 本文讲解在 :ref:GitLab的汉化与CI持续集成gitlab-runner的配置 <con ...

  3. 指定的网络文件夹目前是以其他用户名和密码进行映射的_使用 GitLab CI 与 Argo CD 进行 GitOps 实践

    在现在的云原生世界里面 GitOps 不断的被提及,这种持续交付的模式越来越受到了大家的青睐,我们前面也有文章详细讲解了 GitOps 的相关概念,在网上也可以找到很多关于它的资源,但是关于 GitO ...

  4. GitLab CI/CD

    GitLab CI/CD 是一个内置在GitLab中的工具,用于通过持续方法进行软件开发: Continuous Integration (CI)  持续集成 Continuous Delivery ...

  5. ci 数据库异常捕获_系统地捕获错误:如何通过4个步骤构建GitLab CI测试管道

    ci 数据库异常捕获 by Joyz 通过乔伊斯 系统地捕获错误:如何通过4个步骤构建GitLab CI测试管道 (Catch bugs systematically: how to build a ...

  6. gitlable iphone_使用gitlab ci构建IOS包并发送通知消息到企业微信

    在之前的文章中,我们介绍了使用gitlab ci构建Android包的方法.今天我们介绍使用gitlab ci如何构建IOS包,并且在打包成功或者失败时,如何将消息通知到企业微信. 如果对gitlab ...

  7. 带你深入了解 GitLab CI/CD 原理及流程

    作者:狂乱的贵公子 cnblogs.com/cjsblog/p/12256843.html GitLab CI/CD 是一个内置在GitLab中的工具,用于通过持续方法进行软件开发: Continuo ...

  8. gitlab ci 自动化部署_lt;为什么准备使用GitLab做CICD流水线?/gt;

    本文是<GitLabCI实践>教程基础部分内容,讲述为什么要使用GitLabCICD功能,点击上面图片获取免费公开课报名链接,欢迎报名学习! 传统的应用开发发布模式 开发团队在开发环境中完 ...

  9. winform 项目 发布后比本地运行慢_前端团队基于 GitLab CI/CD 的自动化构建、发布实践,快来学习吧...

    在公司搭建内部 GitLab 平台后,前端活动项目从 SVN 迁移到 GitLab.本文介绍如何基于 GitLab CI/CD 实现自动化构建及发布. 在从 SVN 迁移到 GitLab 和接入 Gi ...

  10. 基于 GitLab CI 的前端工程CI/CD实践

    CI/CD 是 Gitlab 提供的一整套持续集成.持续交付解决方案. 概念:「持续集成(Continuous Integration)」.「持续交付(Continuous Delivery)」和「持 ...

最新文章

  1. 算法系列15天速成——第十天 栈
  2. 【百度地图API】百度API卫星图使用方法和卫星图对比工具
  3. python开发微信小程序-Python实现微信小程序支付功能
  4. 三伏天到了,记得为数据中心降降温
  5. Luogu2495[SDOI2011]消耗战
  6. [计组]寄存器的基本含义
  7. C++ new和delete
  8. php 读取excel转数组中,thinkphp5使用PHPExcel读取excel csv到数组
  9. linux 进程状态 load,Linux - 系统指标 CPU load
  10. php navigator,微信小程序组件:navigator页面链接解读和分析
  11. linux分享二:Linux如何修改字符集
  12. 计算机操作系统慕课版(汤小丹)--第一章课后题
  13. 茫茫社招路,硕士毕业半年的抉择
  14. 用VMWARE安装Mac OSX Tiger 10.4.4 X86
  15. GitHub每月优秀热门项目推荐:2021年12月
  16. [Android O] [RK3399] -- Vendor Storage 功能探究
  17. 三秒让你学会公私网地址转换(NAT)
  18. LPC1768 IAP写入bin格式程序不能启动的解决办法
  19. 冬至计算(一千年冬至计算)
  20. [转]String 之 new String()和 intern()方法深入分析

热门文章

  1. 中国软件正版化的理想模型
  2. java 集合类 map/set/list/vector之间的关系
  3. 【Hibernate】Hibernate中查询表名、字段名以及字段类型等信息
  4. nyoj 寻找最大数
  5. Android中Messenger的使用
  6. mysql中utf8_general_cs和utf8_general_ci和utf8_bin的一点区
  7. linux下gcc升级
  8. 【技术贴】红警三卡||红警三卡在游戏开始界面卡在右上角小星星卡在美女界面卡在创建名字黑屏的解决方案...
  9. 50多个强大的jQuery插件应用实例
  10. SpringBoot 实战:如何从零开发 “淘宝”