Apache DevLake 中 GitHub Actions 工作流名称采集问题解析

在持续集成/持续部署(CI/CD)流程监控领域，Apache DevLake 作为一个开源的数据湖解决方案，能够从各种开发工具中收集和分析数据。其中对 GitHub Actions 工作流的支持是其重要功能之一。然而，当工作流中使用了 run-name 参数时，系统在采集数据时会出现工作流名称显示不一致的问题。

问题背景

GitHub Actions 允许用户通过 run-name 参数自定义工作流运行的显示名称。这个功能非常有用，特别是在需要动态生成运行名称的场景下，比如根据输入参数或环境变量来命名。然而，在 DevLake 的数据采集过程中，当工作流定义了 run-name 时，系统会将动态生成的显示名称(display_title)而非原始工作流名称记录到数据库的 name 字段中。

这种不一致性导致了两个主要问题：

1. 在 _tool_github_runs 和 cicd_pipelines 表中，相同工作流的运行记录可能显示不同的名称
2. 用户难以基于工作流名称进行统一的查询和统计分析

技术分析

从技术实现角度看，这个问题源于 GitHub API 返回的数据结构和 DevLake 数据处理逻辑的交互方式。GitHub API 对于定义了 run-name 的工作流运行，会返回两个相关的名称字段：

• 工作流本身的名称(workflow name)
• 运行时生成的显示名称(display_title)

当前 DevLake 的实现直接使用了 API 返回的显示名称作为 name 字段的值，而没有考虑工作流原始名称的保留需求。这种做法虽然简化了实现，但在实际使用中造成了数据一致性问题。

解决方案探讨

针对这个问题，可以考虑以下几种技术方案：

1. 双字段存储方案：同时保留工作流原始名称和运行时显示名称，在数据库中添加额外字段分别存储。这种方案最完整，但需要修改数据库结构。

2. 智能选择方案：在数据处理层实现逻辑，优先使用工作流原始名称，只有在没有定义时才使用显示名称。这种方案保持现有数据结构不变。

3. 配置化方案：允许用户通过配置选择使用哪种名称，提供更大的灵活性。

从实用性和实现成本角度考虑，第一种双字段存储方案最为合理。它不仅解决了当前问题，还为未来可能的分析需求提供了更多数据维度。具体实现可以：

• 在 _tool_github_runs 表中添加 workflow_name 字段存储原始名称
• 保持现有 name 字段存储运行时显示名称
• 在数据转换到 cicd_pipelines 时，根据用户需求选择使用哪个字段

实现建议

对于希望自行解决此问题的开发者，可以参考以下实现步骤：

1. 修改 GithubRun 数据模型，添加 workflow_name 字段
2. 更新 GitHub API 数据采集逻辑，正确填充两个名称字段
3. 调整数据转换逻辑，确保 cicd_pipelines 表中的数据一致性
4. 提供配置选项，让用户决定在报表和分析中使用哪个名称

这种实现方式既保持了向后兼容性，又解决了名称显示不一致的问题，同时为高级分析场景提供了更多可能性。

总结

GitHub Actions 工作流名称采集问题看似简单，实则反映了数据采集系统中常见的源数据多样性与下游使用需求之间的平衡问题。通过合理的架构设计和数据模型扩展，DevLake 可以更好地支持各种 CI/CD 监控场景，为用户提供更准确、更灵活的数据分析能力。