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

在持续集成/持续部署(CI/CD)系统的数据采集过程中，Apache DevLake 项目遇到了一个关于 GitHub Actions 工作流名称采集的特殊情况。本文将深入分析这个问题及其技术背景。

问题现象

当 GitHub Actions 工作流文件中定义了 run-name 属性时，DevLake 采集的流水线数据会出现一个特殊情况：_tool_github_runs 和 cicd_pipelines 表中的 name 字段会使用动态生成的 display_title 而非工作流本身的名称。这给后续的数据查询和统计分析带来了不便。

技术背景

GitHub Actions 提供了 run-name 属性，允许用户为每次工作流运行定义动态名称。这个功能非常有用，特别是在需要区分不同环境或参数的部署场景中。例如：

run-name: "Deploy on ${{ inputs.app_name || github.event.label.name || 'production' }}"

然而，这种灵活性也给数据采集和分析工具带来了挑战。在默认情况下，GitHub API 会返回两种名称信息：

1. 工作流文件本身的静态名称
2. 通过 run-name 生成的动态显示名称

问题影响

当前 DevLake 的实现将所有情况下的名称统一处理，导致：

1. 当工作流使用 run-name 时，采集的名称不一致
2. 难以对相同工作流的不同运行进行聚合分析
3. 仪表板和报表中的数据呈现不一致

解决方案探讨

从技术角度看，理想的解决方案应该考虑以下几点：

1. 数据完整性：保留 GitHub API 提供的所有相关信息
2. 查询便利性：确保用户能够方便地按工作流类型或特定运行进行筛选
3. 向后兼容：不影响现有查询和报表

可能的实现方案包括：

1. 双字段存储：在数据库表中同时存储工作流名称和运行名称
2. 智能名称选择：根据上下文自动选择最合适的名称显示
3. 元数据扩展：将额外信息存储在扩展字段中

技术实现建议

基于项目现状，推荐采用双字段存储方案：

1. 在 _tool_github_runs 表中新增 workflow_name 字段
2. 保持现有 name 字段不变（存储动态名称）
3. 在数据转换层提供逻辑，允许用户选择使用哪个名称

这种方案的优势在于：

• 不破坏现有功能
• 提供最大灵活性
• 易于实现和理解

总结

GitHub Actions 的动态命名功能为 CI/CD 流程带来了灵活性，但也给数据采集工具提出了新的要求。Apache DevLake 作为一款优秀的 DevOps 数据采集和分析平台，需要妥善处理这类特殊情况，以提供准确、一致的数据分析能力。通过合理的架构设计和技术实现，可以完美解决这一问题，为用户提供更好的使用体验。