Electron-Builder 在 GitHub Actions 中使用 Azure Trusted Signing 的并发问题解析

问题背景

在 Electron 应用开发中，使用 electron-builder 进行 Windows 平台打包时，许多开发者会选择 Azure Trusted Signing 服务进行代码签名。然而，在 GitHub Actions 等 CI/CD 环境中，当应用包含多个需要签名的可执行文件时，会出现并发签名导致的问题。

核心问题表现

当 electron-builder 在 GitHub Actions 中尝试同时签名多个文件时，会出现以下典型错误：

Install-Package: Package 'Microsoft.Trusted.Signing.Client' failed to be installed because: The process cannot access the file
'C:\Users\runneradmin\AppData\Local\TrustedSigning\Microsoft.Trusted.Signing.Client\Microsoft.Trusted.Signing.Client.1.0
.53\bin\x64\Azure.CodeSigning.Dlib.dll' because it is being used by another process.

这个问题的根源在于 electron-builder 默认会以并发方式（concurrency=4）签名多个文件，而 Azure Trusted Signing 在签名前需要安装必要的模块。当多个签名进程同时运行时，它们都会尝试安装相同的模块，导致文件访问冲突。

技术原理分析

1. 签名流程：electron-builder 在签名 Windows 应用时，会处理主可执行文件、资源文件、解压后的 ASAR 文件等多个目标。

2. 并发机制：默认情况下，electron-builder 使用 Bluebird 的 map 方法以并发方式处理签名任务，提高整体构建速度。

3. Azure Trusted Signing 特殊性：该服务需要在每次签名前验证并安装必要的 PowerShell 模块和依赖项，这在并发环境下会导致资源竞争。

解决方案演进

electron-builder 社区针对此问题提出了几种解决方案：

1. 串行签名方案：最直接的解决方法是强制签名过程串行执行。通过修改 winPackager.js 中的签名逻辑，将并发 map 调用改为顺序执行的 for 循环。

2. 条件并发控制：更优雅的方案是检测是否使用 Azure Trusted Signing，如果是则自动禁用并发签名。

3. 批量签名优化：Azure Trusted Signing 本身支持批量签名多个文件，electron-builder 可以优化为收集所有需要签名的文件后一次性提交。

实际应用建议

对于正在使用 electron-builder v26.0.0-alpha.4 及以上版本的用户：

1. 确保使用最新版本，该版本已内置了对 Azure Trusted Signing 并发问题的修复。

2. 如果仍遇到问题，可以考虑在 GitHub Actions 中预先安装必要的模块：

Install-Module -Name TrustedSigning -RequiredVersion 0.4.1 -Force -Repository PSGallery -Scope CurrentUser

3. 对于自定义需求，可以通过 patch-package 临时修改 electron-builder 的签名逻辑。

最佳实践

1. 在 CI/CD 环境中，优先考虑使用 electron-builder 的官方解决方案而非自行修改。

2. 监控签名过程中的资源使用情况，适当调整并发级别。

3. 对于大型项目，考虑将签名步骤分离为独立的工作流，减少与其他构建步骤的相互影响。

总结

electron-builder 与 Azure Trusted Signing 的集成在 GitHub Actions 中的并发问题，反映了现代构建工具在效率与可靠性之间的平衡挑战。通过理解问题的技术本质和解决方案的演进过程，开发者可以更有效地构建稳定的 Electron 应用发布流程。随着 electron-builder 的持续更新，这类问题将得到更好的原生支持。