GitLab CI/CD Variables 中文文档

  • A+
所属分类:自动化运维

Variables

官方文档:https://docs.gitlab.com/ce/ci/variables/README.html

当GitLab CI 中接受到一个job后,Runner就开始准备构建环境??忌柚迷ざㄒ宓谋淞?环境变量)和用户自定义的变量。

variables 的执行顺序

变量可以被重写,并且是按照下面的顺序进行执行:

  1. Trigger variables(优先级最高)
  2. Secret variables
  3. YAML-defined?job-level variables
  4. YAML-defined?global variables
  5. Deployment variables
  6. Predefined variables?(优先级最低)

举个例子,如果你定义了私有变量API_TOKEN=secure,并且在.gitlab-ci.yml中定义了?API_TOKEN=yaml,那么私有变量API_TOKEN的值将是secure,因为secret variables的优先级较高。

Predefined variables(Environment variables)

有部分预定义的环境变量仅仅只能在最小版本的GitLab Runner中使用。请参考下表查看对应的Runner版本要求。

注意:从GitLab 9.0 开始,部分变量已经不提倡使用。请查看9.0 Renaming部分来查找他们的替代变量。强烈建议使用新的变量,我们也会在将来的GitLab版本中将他们移除。

Variable GitLab Runner Description
CI all 0.4 标识该job是在CI环境中执行
CI_COMMIT_REF_NAME 9.0 all 用于构建项目的分支或tag名称
CI_COMMIT_REF_SLUG 9.0 all 先将$CI_COMMIT_REF_NAME的值转换成小写,最大不能超过63个字节,然后把除了0-9a-z的其他字符转换成-。在URLs和域名名称中使用。
CI_COMMIT_SHA 9.0 all commit的版本号
CI_COMMIT_TAG 9.0 0.5 commit的tag名称。只有创建了tags才会出现。
CI_DEBUG_TRACE 9.0 1.7 debug tracing开启时才生效
CI_ENVIRONMENT_NAME 8.15 all job的环境名称
CI_ENVIRONMENT_SLUG 8.15 all 环境名称的简化版本,适用于DNS,URLs,Kubernetes labels等
CI_JOB_ID 9.0 all GItLab CI内部调用job的一个唯一ID
CI_JOB_MANUAL 8.12 all 表示job启用的标识
CI_JOB_NAME 9.0 0.5 .gitlab-ci.yml中定义的job的名称
CI_JOB_STAGE 9.0 0.5 .gitlab-ci.yml中定义的stage的名称
CI_JOB_TOKEN 9.0 1.2 用于同GitLab容器仓库验证的token
CI_REPOSITORY_URL 9.0 all git仓库地址,用于克隆
CI_RUNNER_DESCRIPTION 8.10 0.5 GitLab中存储的Runner描述
CI_RUNNER_ID 8.10 0.5 Runner所使用的唯一ID
CI_RUNNER_TAGS 8.10 0.5 Runner定义的tags
CI_PIPELINE_ID 8.10 0.5 GitLab CI 在内部使用的当前pipeline的唯一ID
CI_PIPELINE_TRIGGERED all all 用于指示该job被触发的标识
CI_PROJECT_DIR all all 仓库克隆的完整地址和job允许的完整地址
CI_PROJECT_ID all all GitLab CI在内部使用的当前项目的唯一ID
CI_PROJECT_NAME 8.10 0.5 当前正在构建的项目名称(事实上是项目文件夹名称)
CI_PROJECT_NAMESPACE 8.10 0.5 当前正在构建的项目命名空间(用户名或者是组名称)
CI_PROJECT_PATH 8.10 0.5 命名空间加项目名称
CI_PROJECT_PATH_SLUG 9.3 all $CI_PROJECT_PATH小写字母、除了0-9a-z的其他字母都替换成-。用于地址和域名名称。
CI_PROJECT_URL 8.10 0.5 项目的访问地址(http形式)
CI_REGISTRY 8.10 0.5 如果启用了Container Registry,则返回GitLab的Container Registry的地址
CI_REGISTRY_IMAGE 8.10 0.5 如果为项目启用了Container Registry,它将返回与特定项目相关联的注册表的地址
CI_REGISTRY_PASSWORD 9.0 all 用于push containers到GitLab的Container Registry的密码
CI_REGISTRY_USER 9.0 all 用于push containers到GItLab的Container Registry的用户名
CI_SERVER all all 标记该job是在CI环境中执行
CI_SERVER_NAME all all 用于协调job的CI服务器名称
CI_SERVER_REVISION all all 用于调度job的GitLab修订版
CI_SERVER_VERSION all all 用于调度job的GItLab版本
ARTIFACT_DOWNLOAD_ATTEMPTS 8.15 1.9 尝试运行下载artifacts的job的次数
GET_SOURCES_ATTEMPTS 8.15 1.9 尝试运行获取源的job次数
GITLAB_CI all all 用于指示该job是在GItLab CI环境中运行
GITLAB_USER_ID 8.12 all 开启该job的用户ID
GITLAB_USER_EMAIL 8.12 all 开启该job的用户邮箱
RESTORE_CACHE_ATTEMPTS 8.15 1.9 尝试运行存储缓存的job的次数

9.0 Renaming

根据GitLab的命名规则,在9.0以后将从build术语转到jobCI变量中,并且已经被重命名。

8.x name 9.0+ name
CI_BUILD_ID CI_JOB_ID
CI_BUILD_REF CI_COMMIT_SHA
CI_BUILD_TAG CI_COMMIT_TAG
CI_BUILD_REF_NAME CI_COMMIT_REF_NAME
CI_BUILD_REF_SLUG CI_COMMIT_REF_SLUG
CI_BUILD_NAME CI_JOB_NAME
CI_BUILD_STAGE CI_JOB_STAGE
CI_BUILD_REPO CI_REPOSITORY_URL
CI_BUILD_TRIGGERED CI_PIPELINE_TRIGGERED
CI_BUILD_MANUAL CI_JOB_MANUAL
CI_BUILD_TOKEN CI_JOB_TOKEN

.gitlab-ci.yaml?defined variables

注意:此功能要求GitLab Runner 0.5或者更高版本,并且GitLab CI 7.14或者更高版本

GitLab CI允许你向.gitlab-ci.yml中添加变量,这个变量在构建环境中设置。因此,变量将保存在存储中,他们用于存储非敏感的项目配置,例如:RAILS_ENV或者DATABASE_URL。

举个例子,如果将变量设置为全局以下(不是在一个作业中),则它将用于所有执行的命令脚本中:

YAML中定义的变量也将应用到所有创建的服务容器中,因此可以对它进行微调。

变量可以定义为全局,同时也可以定义为job级别。若要关闭作业中的全局定义变量,请定义一个空hash:

您可以在变量定义中使用其他变量(或使用$$将其转义):

Secret variables

注意:

  • 这个功能需要GitLab Runner 0.4.0或者更高版本。
  • 请注意,私有变量不会隐藏,如果明确要这么做,他们的值可以显示在job日志中。如果您的项目是公共的或内部的,你可以在项目的pipeline中设置pipeline为私有的。关于私有变量的讨论在issue?*&####&*_16_*&####&*。

GitLab CI允许你在构建环境过程中设置项目的私有变量。私有变量存储在仓库(.gitlab-ci.yml)中,并被安全的传递给GitLab Runner,使其在构建环境中可用。建议使用该方法存储诸如密码、秘钥和凭据之类的东西。

可用通过Settings ? Pipelines来增加私有变量,通过Settings ? Pipelines找到的??槌浦接斜淞?。

一次设置,所有的后续pipeline是都可以使用它们。

Protected secret variables

注意:此功能要求GitLab 9.3或者更高。

私有变量可以被?;?。每当一个私有变量被?;な?,它只会安全的传递到在受?;さ姆种?/a>或受?;さ谋昵?/a>上运行的pipeline。其他的pipeline将不会得到受?;さ谋淞?。

可用通过Settings ? Pipelines来增加私有变量,通过Settings ? Pipelines找到的??槌浦接斜淞?,然后点击Protected。

一次设置,所有的后续pipeline是都可以使用它们。

Deploment variables

注意:此功能要求GitLab CI 8.15或者更高版本。

负责部署配置的项目服务可以定义在构建环境中设置自己的变量。这些变量只定义用于部署job。请参考您正在使用的项目服务的文档,以了解他们定义的变量。

一个定义有部署变量的项目服务示例Kubernetes Service。

Debug tracing

GitLab Runner 1.7开始引入。

警告:启用调试跟踪可能会严重的安全隐患。输出内容将包含所有的私有变量和其他的隐私!输出的内容将被上传到GitLab服务器并且将会在job记录中明显体现。

默认情况下,GitLab Runner会隐藏了处理job时正在做的大部分细节。这种行为使job跟踪很短,并且防止秘密泄露到跟踪中,除非您的脚本将他们输出到屏幕中。

如果job没有按照预期的运行,这也会让问题查找变得更加困难;在这种情况下,你可以在.gitlab-ci.yml中开启调试记录。它需要GitLab Runner v1.7版本以上,此功能可启用shell的执行记录,从而产生详细的job记录,列出所有执行的命令,设置变量等。

在启用此功能之前,您应该确保job只对团队成员可见。您也应该https://docs.gitlab.com/ce/ci/pipelines.html#seeing-build-status所有生成的job记录,然后使其可见。

设置CI_DEBUG_TRACE变量的值为true来开启调试记录。

调试记录设置为TRUE的截断输出示例:

Using the CI variables in your job scripts

在构建环境变量时,所有的变量都被设置为环境变量,他们可以使用普通方法访问这些变量。在大多数情况下,用于执行job脚本都是通过bash或者是sh。

想要访问环境变量,请示使用一下Runner对应的语法:

Shell 用法
bash/sh $variable
windows batch %variable%
PowerShell $env:variable

在bash中访问环境变量,需要给变量名称加上前缀($):

在Windows系统的PowerShell中访问环境变量,需要给变量名称加上前缀($env:):

您可以使用export命令来列出所有的环境变量。在使用此命令时要注意,此命令也会在job记录中列出所有私有变量的值:

实例的值:

weinxin
微信公众号
扫一扫关注运维生存时间公众号,获取最新技术文章~

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:1   其中:访客  1   博主  0

    • Fennay 0

      请注明来源,谢谢
      https://fennay.github.io/gitlab-ci-cn/variables.html