Digger项目中PR锁定机制的演进与优化

背景与问题起源

在基础设施即代码(IaC)领域，并发操作控制是保证系统稳定性的关键要素。Digger作为一款开源基础设施编排工具，早期版本通过CLI参数disable-locking来控制PR(拉取请求)的锁定行为。该机制在纯CLI模式下运作良好，但随着架构演进为混合模式(CLI+Orchestrator)，特别是当锁定逻辑迁移至数据库层后，原有设计暴露出控制盲区——Orchestrator模式无法再通过CLI参数禁用锁定功能。

技术方案重构

开发团队识别到这一架构断层后，决定将锁定控制权上移至核心配置文件digger.yml中。这一调整带来三个显著优势：

1. 配置统一化：所有运行模式(CLI/Orchestrator)共享同一配置源
2. 声明式管理：锁定策略成为基础设施声明的一部分
3. 前后端协同：后端服务可直接读取配置决定是否跳过锁检查

值得注意的是，新方案采用了更符合行为语义的pr_locks: false配置项，替代原先的disable_locking否定式语法。这种正向表述更符合基础设施配置的最佳实践，使"启用PR锁"成为默认安全状态，而显式声明false时才禁用。

实现细节与影响

在技术实现层面，该变更涉及多组件协同：

• 前端解析：Digger CLI优先读取digger.yml中的pr_locks配置
• 后端处理：Orchestrator服务通过webhook获取配置后动态调整锁策略
• 迁移兼容：旧参数被标记为废弃但保持短期兼容

这种设计尤其适合复杂CI/CD流水线场景。例如当多个团队协作时，可以在项目级配置中统一管理锁定策略，避免因个别PR的特殊参数导致全局状态不一致。

最佳实践建议

对于使用者而言，建议：

1. 新项目直接采用pr_locks配置项
2. 存量项目在升级时检查锁定行为是否符合预期
3. 在monorepo结构中，可通过项目级配置实现细粒度控制

该改进体现了Digger团队对配置治理的深入思考——将运行时参数逐步收敛至声明式配置，这为未来实现策略即代码(Policy as Code)奠定了良好基础。