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版本中将他们移除。

VariableGitLabRunnerDescription
CIall0.4标识该job是在CI环境中执行
CI_COMMIT_REF_NAME9.0all用于构建项目的分支或tag名称
CI_COMMIT_REF_SLUG9.0all先将$CI_COMMIT_REF_NAME的值转换成小写,最大不能超过63个字节,然后把除了0-9a-z的其他字符转换成-。在URLs和域名名称中使用。
CI_COMMIT_SHA9.0allcommit的版本号
CI_COMMIT_TAG9.00.5commit的tag名称。只有创建了tags才会出现。
CI_DEBUG_TRACE9.01.7debug tracing开启时才生效
CI_ENVIRONMENT_NAME8.15alljob的环境名称
CI_ENVIRONMENT_SLUG8.15all环境名称的简化版本,适用于DNS,URLs,Kubernetes labels等
CI_JOB_ID9.0allGItLab CI内部调用job的一个唯一ID
CI_JOB_MANUAL8.12all表示job启用的标识
CI_JOB_NAME9.00.5.gitlab-ci.yml中定义的job的名称
CI_JOB_STAGE9.00.5.gitlab-ci.yml中定义的stage的名称
CI_JOB_TOKEN9.01.2用于同GitLab容器仓库验证的token
CI_REPOSITORY_URL9.0allgit仓库地址,用于克隆
CI_RUNNER_DESCRIPTION8.100.5GitLab中存储的Runner描述
CI_RUNNER_ID8.100.5Runner所使用的唯一ID
CI_RUNNER_TAGS8.100.5Runner定义的tags
CI_PIPELINE_ID8.100.5GitLab CI 在内部使用的当前pipeline的唯一ID
CI_PIPELINE_TRIGGEREDallall用于指示该job被触发的标识
CI_PROJECT_DIRallall仓库克隆的完整地址和job允许的完整地址
CI_PROJECT_IDallallGitLab CI在内部使用的当前项目的唯一ID
CI_PROJECT_NAME8.100.5当前正在构建的项目名称(事实上是项目文件夹名称)
CI_PROJECT_NAMESPACE8.100.5当前正在构建的项目命名空间(用户名或者是组名称)
CI_PROJECT_PATH8.100.5命名空间加项目名称
CI_PROJECT_PATH_SLUG9.3all$CI_PROJECT_PATH小写字母、除了0-9a-z的其他字母都替换成-。用于地址和域名名称。
CI_PROJECT_URL8.100.5项目的访问地址(http形式)
CI_REGISTRY8.100.5如果启用了Container Registry,则返回GitLab的Container Registry的地址
CI_REGISTRY_IMAGE8.100.5如果为项目启用了Container Registry,它将返回与特定项目相关联的注册表的地址
CI_REGISTRY_PASSWORD9.0all用于push containers到GitLab的Container Registry的密码
CI_REGISTRY_USER9.0all用于push containers到GItLab的Container Registry的用户名
CI_SERVERallall标记该job是在CI环境中执行
CI_SERVER_NAMEallall用于协调job的CI服务器名称
CI_SERVER_REVISIONallall用于调度job的GitLab修订版
CI_SERVER_VERSIONallall用于调度job的GItLab版本
ARTIFACT_DOWNLOAD_ATTEMPTS8.151.9尝试运行下载artifacts的job的次数
GET_SOURCES_ATTEMPTS8.151.9尝试运行获取源的job次数
GITLAB_CIallall用于指示该job是在GItLab CI环境中运行
GITLAB_USER_ID8.12all开启该job的用户ID
GITLAB_USER_EMAIL8.12all开启该job的用户邮箱
RESTORE_CACHE_ATTEMPTS8.151.9尝试运行存储缓存的job的次数

9.0 Renaming

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

8.x name9.0+ name
CI_BUILD_IDCI_JOB_ID
CI_BUILD_REFCI_COMMIT_SHA
CI_BUILD_TAGCI_COMMIT_TAG
CI_BUILD_REF_NAMECI_COMMIT_REF_NAME
CI_BUILD_REF_SLUGCI_COMMIT_REF_SLUG
CI_BUILD_NAMECI_JOB_NAME
CI_BUILD_STAGECI_JOB_STAGE
CI_BUILD_REPOCI_REPOSITORY_URL
CI_BUILD_TRIGGEREDCI_PIPELINE_TRIGGERED
CI_BUILD_MANUALCI_JOB_MANUAL
CI_BUILD_TOKENCI_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 CI允许你在构建环境过程中设置项目的私有变量。私有变量存储在仓库(.gitlab-ci.yml)中,并被安全的传递给GitLab Runner,使其在构建环境中可用。建议使用该方法存储诸如密码、秘钥和凭据之类的东西。

可用通过Settings ➔ Pipelines来增加私有变量,通过Settings ➔ Pipelines找到的模块称之为私有变量。

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

Protected secret variables

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

私有变量可以被保护。每当一个私有变量被保护时,它只会安全的传递到在受保护的分支受保护的标签上运行的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记录中列出所有私有变量的值:

 

实例的值: