深入解析act项目中可复用工作流的输入参数传递问题

问题背景

在GitHub Actions的自动化流程中，可复用工作流(Reusable Workflow)是一种强大的功能，它允许开发者将通用的工作流逻辑封装起来，供多个项目或工作流调用。然而，在使用nektos/act项目(一个本地运行GitHub Actions的工具)时，开发者遇到了一个关于输入参数传递的棘手问题。

问题现象

当主工作流调用可复用工作流时，如果可复用工作流中同时定义了workflow_call和workflow_dispatch两种触发方式的输入参数，act工具会错误地使用workflow_dispatch的默认值，而不是主工作流传递的实际参数值。这导致自动化流程无法按预期执行。

技术分析

输入参数定义冲突

在可复用工作流的定义中，开发者通常会为不同的触发方式定义输入参数。例如：

on:
  workflow_dispatch:
    inputs:
      passed_input:
        type: string
        required: true
        default: "default_value_dispatch"
  workflow_call:
    inputs:
      passed_input:
        type: string
        required: true
        default: "default_value_call"

理论上，当工作流被其他工作流调用时(workflow_call)，应该使用对应的输入参数定义和传递的值。然而act工具在当前实现中存在逻辑缺陷。

底层实现问题

通过分析act的源代码，可以发现：

1. 可复用工作流的执行器(ReusableWorkflowRunner)在初始化时，错误地使用了包含workflow_dispatch事件信息的运行上下文(rc)
2. 虽然计划阶段(PlanEvent)正确地识别了workflow_call事件，但在实际执行时却丢失了这一信息
3. 输入参数的传递机制存在缺陷，无法正确地将主工作流传递的值应用到被调用工作流中

影响范围

这个问题会影响所有使用以下配置的开发者：

1. 使用act工具本地测试GitHub Actions工作流
2. 工作流设计中包含可复用工作流
3. 可复用工作流同时支持直接触发(workflow_dispatch)和被调用(workflow_call)
4. 两种触发方式定义了相同名称但不同默认值的输入参数

临时解决方案

目前开发者可以采用以下临时解决方案：

1. 使用act push命令替代直接调用，这可以绕过部分参数传递问题
2. 在测试时，暂时移除可复用工作流中的workflow_dispatch输入定义
3. 将两种触发方式的输入参数默认值设为相同，避免行为不一致

技术建议

对于act项目的开发者，建议从以下几个方面进行修复：

1. 确保可复用工作流执行时使用正确的触发事件上下文
2. 完善输入参数的传递机制，优先使用调用方传递的值
3. 在处理可复用工作流时，明确区分不同触发方式的输入参数定义
4. 增加相关测试用例，覆盖这种参数传递场景

总结

act工具中的这个可复用工作流参数传递问题，暴露了本地测试工具与GitHub实际环境之间的行为差异。理解这一问题有助于开发者在设计复杂工作流时做出更合理的架构决策，同时也提醒我们在使用本地测试工具时需要关注其与生产环境的兼容性。随着act项目的持续发展，这类问题有望得到根本解决，为开发者提供更可靠的本地测试体验。