【问题标题】:How to use custom variables in gitlab ci/cd?如何在 gitlab ci/cd 中使用自定义变量?
【发布时间】:2021-06-25 23:22:27
【问题描述】:

我正在为 gitlab ci/cd 变量而苦苦挣扎。我看到很多相互矛盾的例子。总之,我想知道的是如何在脚本内外使用变量。

例如,在作业配置中,我可以使用 bash 命令在脚本部分中分配一个变量吗?

some-job:
   variables:
      SOME_VAR: ''
   script:
      - SOME_VAR = $(<file_with_a_line_of_text.txt)

在上述情况下,我不确定我是否可以这样做。但我需要用文件内容(即工件)填充一个变量。另外,什么时候在变量前面使用“$”?我看到使用这些格式的一些示例:

"SOME_VAR" #in quotes, no dollar sign
"${SOME_VAR}" #in quotes, with dollar sign and wrapped with curly braces
${SOME_VAR} #no quotes, with dollar sign and wrapped with curly braces
$SOME_VAR #i.e. without the double quotes or curly braces
SOME_VAR #i.e. without the double quotes, dollar sign, and curly braces

我可以在示例中看到如此多的用法变化,但并不真正知道何时使用每种样式。而且我在网上找不到一个使用 bash 命令在脚本中设置自定义变量的示例。

【问题讨论】:

  • 也许你应该从shell介绍开始?

标签: bash shell gitlab gitlab-ci


【解决方案1】:

如何在gitlab ci/cd中使用自定义变量?

通常就像在任何其他 shell 中一样。

但是注意gitlab-ci.yml是一个yaml文件,yaml有特殊的解析。因为在script: ex。 - echo bla- 'echo bla' 相同,因为在 yaml 中,script: 的内容是一个字符串数组,稍后会被 shell 吐出。

如何在脚本内外使用变量。

通常就像在任何其他 shell 脚本中一样。

何时使用每种样式

"SOME_VAR" #in quotes, no dollar sign
SOME_VAR #i.e. without the double quotes, dollar sign, and curly braces

当你想要一个字符串 SOME_VAR 字面意思时

"${SOME_VAR}"

"$SOME_VAR" 相同。当你想从字面上获得SOME_VAR 变量的内容时。

${SOME_VAR} #no quotes, with dollar sign and wrapped with curly braces
$SOME_VAR #i.e. without the double quotes or curly braces

当你想要SOME_VAR变量的内容分词和文件名扩展后。这意味着SOME_VAR='*' 然后echo "$SOME_VAR" 将打印*,但echo $SOME_VAR 将打印当前目录中的所有文件。您通常总是想要引用扩展。

${SOME_VAR} 的形式在与其他字符串连接时使用,例如。 $SOME_VARbla 不是 ${SOME_VAR}bla

不要在您的脚本中使用大写变量 - 最好使用小写。优先使用大写变量作为导出变量。注意冲突 - COLUMN PATH USER UID 是已使用变量的示例。

我可以使用 bash 命令在脚本部分分配一个变量吗?

Shell 空间感知var = val执行一个名为 var 的命令,其中有两个参数 =valvar=val 会将字符串 val 分配给名为 var 的变量。做:

- SOME_VAR=$(<file_with_a_line_of_text.txt)

在 gitlab-ci 中,我更喜欢使用 cat,以防我想搬到 alpine。 $(&lt; 是一个 bash 扩展。

- SOME_VAR=$(cat file_with_a_line_of_text.txt)

在具有variables: SOME_VAR 的环境中设置提供SOME_VAR 似乎没有任何意义。

什么时候在变量前面使用'$'?

当你想触发变量扩展时。变量扩展用变量名替换变量值。

使用 http://shellcheck.net 检查您的脚本。阅读https://mywiki.wooledge.org/BashGuide 一个很好的shell 介绍和https://wiki.bash-hackers.org/scripting/obsolete

【讨论】:

  • 所以关于 gitlab ci/cd,如果我在变量下的 .gitlab-ci.yml 中声明一个变量,那么每个阶段的所有作业都应该可以访问该变量,对吗?有没有办法在工作后期更改该变量的内容,以便另一个工作获得更改?我现在苦苦挣扎的是,我声明了 var,在作业中更改它(我也回显它以查看它已更改),然后当我在同一阶段的另一个作业中使用它时,它具有原始值而不是新的。
  • that variable should be accessible to all jobs in each stage, correct 取决于。在“根范围”执行variables: 会将变量导出到所有作业。在工作范围内执行variables: 只会影响那一项工作。请参阅 gitlab 文档。 Is there a way to change the contents of that variable later in a job 当然,只是var=valueso that another job gets the change? 不,每个工作都是它自己的过程。甚至每个作业都在它自己的环境中运行。 Tbh,我担心这样的问题是对 docker 工作方式和流程工作方式的误解的标志 - 请务必研究这些主题。
  • What I'm struggling with now is that I declare the var, change it in a job (I also echo it to see that it has changed), then when I use it in another job in the same stage, it has the original value and not the new one 使用工件在阶段之间传输上下文。在 bash 中,您可以使用 declare -p 序列化变量值,然后只需 source 文件来反序列化它的值。
  • 我正在处理的具体问题是 DAST,api 扫描器期望变量 DAST_API_SPECIFICATION 指向 api 规范。问题是我正在尝试使用工件来构建该 api url,但只有一个脚本才能分配给该变量。示例:DAST_API_SPECIFICATION=$(cat api_url.txt)/swagger.json,但这不起作用,因为需要先声明 var。
  • 如果我不使用 DAST_API_SPECIFICATION,它会尝试查找 /zap/wrk 目录并失败,因为它不存在。我不想为此使用自定义 zap 端点
【解决方案2】:

当我在 bash 中设置变量时,我总是在 = 周围没有空格:

VAR1="some string"
VAR2=23
VAR3=true
VAR4=$(cat /path/to/file.txt)

让我们一次一个地看这些例子:

  1. 您可以通过在字符串周围使用引号将变量设置为字符串。
  2. 您可以将其设置为 int(也可能是 float,但没有亲自使用过)
  3. 您可以将其设置为布尔值
  4. 您可以将其设置为命令的输出。命令在命令内部:$(#command)

现在让我们使用它们:

echo $VAR1
# some string
echo "This is my variable $VAR1"
# This is my variable some string
echo "This is my variable ${VAR1}"
# This is my variable some string
echo ${VAR1}
# some string
echo "Error code ${VAR2}A"
# Error code 23A
echo "Error code $VAR2A"
# Error code --- Note: the variable $VAR2A dosn't exist
echo "Error code ${VAR2}${VAR1}"
# Error code 23some string
echo VAR1
# VAR1
echo "VAR1"
# VAR1

这说明了不同形式之间的区别,但通常,您使用$+variable-name 引用变量的值。执行"SOME_VAR"SOME_VAR 只会打印出字符串“SOME_VAR”(即根本不引用变量)。

$SOME_VAR${SOME_VAR}的区别在于后者可以让你在变量前后直接有其他内容的情况下使用,不会报错。

【讨论】:

    猜你喜欢
    • 2022-07-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-08-07
    • 2022-08-18
    • 2022-01-19
    • 2023-01-13
    • 2021-08-15
    相关资源
    最近更新 更多