本文探讨了在github actions工作流中，将包含多行字符的`.pem`密钥从github secret传递给环境变量时，可能遇到的yaml解析错误。核心问题在于yaml对换行符的处理方式。解决方案是利用yaml的多行字符串字面量（`|`）语法，确保密钥内容作为单个字符串正确解析，从而避免因特殊字符导致的解析失败，确保ci/cd流程的顺畅执行。
GitHub Actions中传递多行密钥的挑战
在自动化部署和持续集成/持续交付（CI/CD）流程中，我们经常需要在GitHub Actions工作流中使用敏感凭证，例如SSH私钥（通常为.pem格式）或API密钥。这些密钥通常以GitHub Secrets的形式存储，以确保安全性。然而，当这些密钥包含多行字符（即换行符）时，直接将其赋值给工作流中的环境变量可能会导致YAML解析错误。
例如，一个典型的.pem密钥会包含如下结构，其中包含多行文本和换行符：
-----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAw... ... -----END RSA PRIVATE KEY-----
当尝试将这样的多行密钥从GitHub Secret（例如 secrets.GITHUBAPP_KEY）直接传递给环境变量时，常见的错误赋值方式如下：
- name: 执行特定步骤
run: echo "执行命令..."
env:
GITHUBAPP_KEY: "${{ secrets.GITHUBAPP_KEY }}"这种写法在执行时，GitHub Actions可能会抛出类似 error: error parsing STDIN: invalid Yaml document separator: --END RSA PRIVATE KEY-----" 的错误。这是因为YAML解析器在处理包含换行符的字符串时，如果没有明确的指示，可能会将换行符误认为是文档分隔符或新的YAML结构元素，从而导致解析失败。尽管使用了双引号，但它们不足以告诉YAML解析器将整个多行内容视为一个单一的字符串字面量。
解决方案：使用YAML多行字符串字面量
为了正确地将包含多行字符的密钥作为单个字符串传递给环境变量，我们需要利用YAML的多行字符串字面量语法，特别是管道符 |。管道符告诉YAML解析器，其后的所有缩进内容都应被视为一个多行字符串，并保留其中的所有换行符。
正确的赋值方式如下：
- name: 执行特定步骤
run: echo "执行命令..."
env:
GITHUBAPP_KEY: |
${{ secrets.GITHUBAPP_KEY }}在这个示例中：
- GITHUBAPP_KEY: 后面紧跟的管道符 | 指示YAML解析器，接下来的内容是一个多行字符串。
- ${{ secrets.GITHUBAPP_KEY }} 会被GitHub Actions在运行时替换为实际的密钥内容。由于 | 的存在，即使密钥内容包含多行，它也会被完整地作为一个环境变量的字符串值传递，所有换行符都将保留在其内部，而不会干扰YAML的解析结构。
工作原理与注意事项
- 保留换行符： 管道符 | 是“字面量块标量”的指示符。它会保留字符串中所有的换行符和缩进（除非额外指定缩进）。这对于.pem密钥这类依赖精确格式（包括换行符）的数据至关重要。
- 缩进： 在 | 之后，${{ secrets.GITHUBAPP_KEY }} 必须有至少一个空格的缩进，以表明它是 GITHUBAPP_KEY 键的值。这个缩进在最终字符串中通常会被剥离，但其存在是YAML语法的一部分。
- 其他多行样式： YAML还提供了“折叠块标量”指示符 >。> 会将所有换行符替换为空格，并将连续的空行替换为单个换行符。对于需要精确保留所有换行符的密钥，| 是更合适的选择。
- 安全性： 始终将敏感数据存储在GitHub Secrets中，而不是直接硬编码在工作流文件中。GitHub Secrets会在运行时安全地注入，并且不会暴露在日志中（除非您明确打印出来）。
- 调试： 如果仍然遇到问题，请确保您的GitHub Secret中存储的密钥本身是正确的，没有额外的空格或损坏。您可以通过临时在工作流中打印密钥的长度或部分内容来辅助调试（但请务必在调试完成后移除这些敏感输出）。
总结
在GitHub Actions中处理多行敏感数据（如.pem密钥）时，理解YAML的多行字符串语法至关重要。通过简单地在环境变量赋值时使用管道符 |，可以有效地解决因换行符导致的YAML解析问题，确保密钥内容作为完整的字符串传递，从而保证CI/CD流程的顺畅和安全。这种方法不仅适用于.pem密钥，也适用于任何需要精确保留换行符的多行字符串数据。
