【问题标题】:GitLab CI/CD unset variables set in CI / CD SettingsGitLab CI/CD 未设置 CI/CD 设置中的变量
【发布时间】:2019-08-07 06:11:21
【问题描述】:

我正在运行一个 gitlab 作业,并且在该作业中我试图取消设置在 CI / CD 设置中设置的某些变量。

例如,我有 SOME_VARIABLE 设置为 <some_value>

然后,在工作定义中,我正在尝试


variables:
   SOME_VARIABLE: ""
script:
    - echo SOME_VARIABLE - [%SOME_VARIABLE%]

但在工作本身我仍然得到

SOME_VARIABLE - [<some_value>]

而不是

SOME_VARIABLE - []

有人遇到过这个吗?

【问题讨论】:

  • 你能展示你的 .gitlabci.yml 文件吗?这可能是由于 Gitlab CI 将脚本之前的双引号解释为空并且仍在重用旧的引起的。也许如果你放一个空格或另一个中性值
  • 是的,多次遇到这种情况,非常烦人。

标签: gitlab gitlab-ci-runner


【解决方案1】:

你不需要=,只需set <varible-name>

例子:

 before_script:
    - set S3_OBJECTS
    - source ./s3-objects.sh

【讨论】:

    【解决方案2】:

    我必须回答这个问题,因为它可能相当晦涩。

    所以当你在 Windows 上设置一个变量时,你不得不说

    set v=some_value

    要取消它,它需要是

    set v=

    不是

    set v=''

    当你将它设置为空字符串时,它就是这样,只是引号:

    $ set v=""
    $ echo %v%
    ""
    

    如果您将其取消设置为正确清空,您会得到:

    $ set v=
    $ echo %v%
    %v%
    

    但是在gitlab中,不能将值留空,比如

    variables:
       v:
    

    因为它的语法无效。

    所以我要做的是在脚本区域取消设置变量:

    script:
      - set v=
      - run_my_script_that_needs_v_unset
    

    然后脚本根据需要运行。

    (我想它可以在其他平台上进行类似的操作。)

    【讨论】:

      【解决方案3】:

      项目 CI/CD 变量优先于 YAML 定义的变量。这是优先顺序。

      1. 触发变量或计划管道变量。
      2. 项目级变量或受保护变量。
      3. 组级变量或受保护变量。
      4. YAML 定义的作业级变量。
      5. YAML 定义的全局变量。
      6. 部署变量。
      7. 预定义的环境变量。

      来自GitLab CI/CD Variables: Priority of variables

      【讨论】:

      • 这在技术上是正确的,但不能回答我的问题。
      猜你喜欢
      • 1970-01-01
      • 2020-01-10
      • 2020-06-21
      • 1970-01-01
      • 2023-03-15
      • 2020-10-27
      • 2021-12-01
      • 2021-09-02
      • 2022-08-11
      相关资源
      最近更新 更多