我的发布流水线拒绝发布我的版本。它是对的。

最近，我遇到了发布流水线拒绝发布我的版本的情况。这次事件不仅挽救了我的项目，还凸显了拥有稳健发布流程的重要性。

事件经过

我为我的项目 agentwatch 发起了一次发布，该项目是 agentsec-ecosystem 中 agent-security 工具的一部分。发布工作流随之启动，执行了多项关键任务：

1. 构建 wheel: 这是创建可轻松安装的包的过程。
2. 生成软件物料清单 (SBOM): 该文档列出了软件中的所有组件，这对安全性和合规性至关重要。
3. 写入校验和: 这些是文件的唯一标识符，用于确保它们未被篡改。
4. 使用 keyless Sigstore 对所有内容进行签名: 这通过验证发布的真实性增加了一层安全性。

然而，工作流在最后一步失败了：在发布前验证版本。我收到的错误信息是：

ModuleNotFoundError: No module named 'cryptography'

这次失败意味着我的 GitHub release 没有生成，这虽然令人沮丧，但归根结底是一件好事。它表明系统正在按预期工作。

为什么会发生这种情况？

失败发生在流水线中原本应该安装并验证发布包的步骤中。失败的具体命令是 agentwatch verify-release，它会在干净的环境中检查构建的工件。该工作流的设计至关重要，因为除非能够成功验证，否则它拒绝发布工件。

在这种情况下，错误源于缺少一个名为 'cryptography' 的模块。该模块没有安装在发布环境中，因为它被视为可选的额外依赖。问题之所以出现，是因为代码试图导入 InvalidSignature 来自顶层的 'cryptography' 模块，这意味着即使在不需要时它也会被加载。

挽救了这次发布的设计

我的发布工作流设计包含一个关键前提条件：如果 agentwatch verify-release 命令无法运行，就什么都不会发布。这个决定将原本可能存在问题的发布转变为一次失败的运行，促使我在它影响到用户之前解决该问题。

错误的 traceback 显示问题出在导入链上。失败之所以发生，是因为 CLI 试图在启动时加载所有内容，包括基本功能不需要的模块。这是软件开发中常见的问题，依赖项可能会引发意料之外的问题。

修复问题

这个问题的修复很简单。我将导入 InvalidSignature 的语句移到了真正需要它的函数内部。这样一来，只有在调用该函数时才会执行导入，从而避免了启动时不必要的加载。以下是修改的简化版本：

def _verify_signature(public: Any, alg: str, signing_input: bytes, signature: bytes) -> bool:
    from cryptography.exceptions import InvalidSignature  # lazy import
    # rest of the function...

这一调整确保了其余代码在运行时不需要 'cryptography' 模块，除非在进行签名验证时明确需要它。

总结

这次经历让我认识到了精心设计的发布流水线的价值。它不仅自动化了部署流程，还充当了安全网，能够捕获可能逃过传统测试方法的问题。

优点

• 防止有缺陷的发布: 在问题影响到用户之前捕获它们。
• 提高代码质量: 通过强制执行检查来促进更好的编码实践。
• 提高可靠性: 建立对发布流程的信任。

缺点

• 初始设置较为复杂: 设计稳健的流水线可能非常耗时。
• 可能存在误报: 有时，正常的发布可能会因严格的检查而被阻止。

注意事项

本文仅供学习参考。在实际场景中，任何占位符值都必须替换为实际值。在依赖任何论断之前，务必根据原始来源进行核实。

常见问题解答

• 什么是发布流水线？ — 发布流水线是准备和部署软件的一系列自动化步骤。
• 为什么发布流水线很重要？ — 它有助于在软件发布给用户之前捕获 bug 和错误，从而提高质量。
• ModuleNotFoundError 是什么意思？ — 它表示当前环境中缺少所需的模块。
• 如何解决 ModuleNotFoundError？ — 确保在你的环境中安装了缺失的模块。
• 什么是软件物料清单 (SBOM)？ — SBOM 是软件包中所有组件的清单，对安全性和合规性非常有用。
• 什么是 keyless Sigstore？ — 一种无需手动管理密钥即可对软件发布进行签名的方法。

标签

#release #pipeline #software #development #automation #quality #security #testing