Moon项目中的任务执行失败处理机制解析

在现代软件开发中，构建工具的任务执行策略对开发者体验有着重要影响。Moon作为一个现代化的构建系统，其任务执行机制提供了灵活的控制能力，特别是在处理任务失败时的行为模式上。

任务执行失败处理的基本原理

Moon默认采用"快速失败"(fail-fast)策略，这种设计哲学认为一旦发现错误就应该立即停止执行，避免在已知错误状态下继续运行可能导致的不可预测行为。当任务图中某个任务失败时，Moon会立即终止整个执行流程，包括所有排队中和未开始的任务。

这种策略在大多数构建场景下是合理的，特别是在依赖关系严格的编译过程中。然而，在某些特定场景下，特别是代码质量检查(linting)这类任务中，开发者更希望看到所有潜在问题，而不是每次只暴露一个错误。

现有解决方案的局限性

Moon目前提供了allowFailure选项作为部分解决方案。当设置为true时，允许任务失败而不中断整个流程。但这种方案存在两个主要限制：

1. 依赖关系限制：标记为allowFailure的任务不能被其他任务依赖，这破坏了任务图的完整性
2. 退出码问题：即使有任务失败，Moon仍会返回0退出码，这使得它无法有效集成到预提交钩子等场景中

改进方案设计思路

Moon内部实际上已经实现了两种失败处理模式，分别应用于moon run(立即失败)和moon ci(最后失败)。基于这一基础，可以考虑以下改进方向：

1. 全局控制选项：通过CLI参数或配置文件提供全局开关，允许开发者选择失败处理策略
2. 细粒度任务控制：为单个任务配置失败传播范围，如"全局"、"项目内"、"下游"或"无"

行业实践参考

其他构建工具在处理类似需求时采用了不同命名：

• Nx、Jest、Vitest使用--bail参数
• Buck2采用--fail-fast和--keep-going对偶参数
• Bazel使用--keep_going
• Turborepo和Lage选择--continue

这些实践表明，失败处理策略的参数命名虽然多样，但核心思想相似：要么立即停止，要么尽可能继续执行。

实现建议

基于Moon现有架构和行业实践，推荐实现方案应包含：

1. 新增--continue参数作为简单开关
2. 考虑支持更灵活的--on-failure枚举参数，接受如"bail"(默认)、"continue"等值
3. 确保任务摘要功能在两种模式下都能正确显示失败状态

这种改进将使Moon在代码质量检查等场景中更加实用，同时保持其在传统构建场景中的可靠性。开发者可以根据具体需求选择最适合的执行策略，平衡快速反馈和全面检查的不同需求。