GitLab CI/CD SSH连EC2执行docker-compose单引号生效原因

命令从输入到最终在远程EC2实例上执行，会经过多层解析，不同写法在不同环境下的解析规则不同，最终传到远程端的命令内容存在差异，直接导致执行结果不同。
针对GitLab CI场景，解析顺序从先到后为：.gitlab-ci.yml的YAML语法解析 → GitLab Runner所在环境的本地Shell解析 → SSH参数传递 → 远程EC2实例的Shell解析。Windows终端手动执行命令时，不存在YAML解析这一层。 #

三种写法的具体执行逻辑 #

可正常运行的单引号写法 #

ssh  -o StrictHostKeyChecking=no  -i $sshKey $user@$host 'docker-compose -v'

• 该写法下，命令里的单引号是POSIX标准Shell（GitLab Runner默认使用的bash/sh均属于此类）的强引用标记：
  • 单引号包裹的内容不会被本地Shell做任何变量替换、命令展开、空格拆分，会原封不动作为完整的远程执行参数传给SSH
  • YAML语法不会对单引号包裹的内部内容做额外转义处理，不会修改命令结构
• 远程EC2端收到完整的docker-compose -v命令，可直接正常执行。

无引号写法的失败原因 #

ssh  -o StrictHostKeyChecking=no  -i $sshKey $user@$host docker-compose -v 

没有引号包裹远程命令时，本地Shell会默认按空格拆分所有参数：最终传给SSH的远程执行内容只有docker-compose，后面的-v会被识别为SSH命令自身的参数，而非远程docker-compose的参数。远程端收到的命令残缺，自然无法正常运行。

双引号写法的跨环境差异原因 #

ssh  -o StrictHostKeyChecking=no  -i $sshKey $user@$host "docker-compose -v"

GitLab CI环境下执行失败的原因：

1. YAML语法对双引号有特殊处理规则：如果双引号是YAML层面的字符串边界标记，解析后引号会被直接移除，命令会退化为和无引号写法一致的参数拆分状态；就算双引号属于命令内容的一部分，YAML也会对双引号内的转义序列（比如\n、\$）做提前解析，很容易修改命令的原始结构。
2. 就算YAML没有修改命令，POSIX Shell中双引号属于弱引用：双引号内的内容会被本地Shell提前做变量替换、命令别名展开，如果命令中包含特殊字符、本地不存在的变量引用，最终传到远程的命令会和预期不一致。

Windows终端下执行正常的原因：

Windows终端（cmd/PowerShell）手动执行命令时没有YAML前置解析层，且Windows Shell的双引号规则会将包裹内的所有内容作为完整参数传给SSH，不会提前做拆分、展开操作，因此命令可以正常传到远程端执行。 #

实操建议：在GitLab CI中通过SSH执行远程命令时，优先用单引号包裹固定的远程命令段，需要传递本地环境变量到远程时，再将变量放在单引号外部拼接，可最大程度避免多层解析带来的语法冲突。

内容的提问来源于stack exchange，提问作者kevP-Sirius