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

9.0 Renaming

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

.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或者更高。

私有变量可以被保护。每当一个私有变量被保护时，它只会安全的传递到在受保护的分支或受保护的标签上运行的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对应的语法：

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

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

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

实例的值：

成长的对话版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！