CoolProp项目工作流构建失败问题分析与解决

CoolProp项目工作流构建失败问题分析与解决

CoolProp Thermophysical properties for the masses 项目地址: https://gitcode.com/gh_mirrors/co/CoolProp

问题背景

在CoolProp项目的持续集成环境中，近期出现了工作流构建失败的问题。主要原因是GitHub Actions中使用的artifact相关操作版本已过时，特别是actions/Upload-artifacts@v3版本即将在2025年1月30日被弃用。这个问题影响了多个构建流程的正常运行。

问题分析

经过深入排查，发现以下几个关键问题点：

1. 过时的Artifact操作版本：项目中的部分工作流仍在使用已被标记为弃用的v3版本artifact操作，这直接导致了构建失败。

2. 依赖链问题：项目中使用的dawidd6/action-download-artifact@v6间接依赖于旧版artifact操作，形成了技术债务。

3. 功能替代方案：GitHub官方actions/artifact工具包已经更新，现在支持通过通配符收集多个构建产物，这使得原本使用第三方解决方案(dawidd6)的必要性降低。

解决方案

针对上述问题，采取了以下解决措施：

1. 升级关键依赖：

   • 将dawidd6/action-download-artifact从v6升级到v8版本
   • 将所有相关的artifact操作更新到v4版本

2. 重构构建产物管理：

   • 为每个构建产物采用唯一命名规则："build-<工作流名称>"
   • 使用通配符模式("build-*")统一收集所有构建产物

3. 分步验证：

   • 首先修复了Clang编译器检查、文档构建等基础工作流
   • 逐步验证JavaScript、LibreOffice等其他构建流程
   • 暂时移除了Mathcad包装构建以简化问题范围

实施效果

经过上述调整后：

• 核心构建流程(Clang检查、文档构建、库构建等)已恢复正常
• 夜间构建任务重新开始运行并成功上传至SourceForge
• 项目网站能够正常更新

遗留问题

虽然大部分问题已解决，但仍存在两个待处理事项：

1. Python wheel构建：构建成功但PyPI服务器认为版本已存在，需要进一步排查版本管理问题。

2. CodeQL检查：因上传对象数量超过限制而失败，考虑通过分割检查范围来解决。

3. Catch2测试：由于求解器调整导致验证值轻微偏差，需要重新校准测试预期值。

经验总结

此次问题的解决过程提供了宝贵的经验：

1. 依赖管理：需要定期检查项目依赖的第三方Actions，及时更新以避免弃用影响。

2. 构建标准化：采用一致的构建产物命名规范可以简化后续的收集和发布流程。

3. 渐进式修复：分步骤验证各工作流可以更有效地定位和解决问题。

这次修复不仅解决了当前的构建问题，还为项目建立了更健壮的持续集成基础架构，有助于未来的维护和扩展。

CoolProp Thermophysical properties for the masses 项目地址: https://gitcode.com/gh_mirrors/co/CoolProp