深入解析tj-actions/changed-files项目中路径参数与GitHub API的兼容性问题

在持续集成/持续部署(CI/CD)流程中，tj-actions/changed-files是一个非常实用的GitHub Action，它可以帮助开发者识别代码库中发生变更的文件。然而，在使用过程中，开发者可能会遇到一个特定场景下的兼容性问题——当尝试结合使用path参数与GitHub API方式时，会出现工作目录不存在的错误。

问题现象

当开发者在不预先执行代码检出(checkout)操作的情况下，直接使用tj-actions/changed-files的GitHub API方式（通过pull_request权限读取变更文件），同时设置了path参数时，会收到类似以下的错误提示：

Error: The cwd: /home/runner/work/<项目路径> does not exist!

这种错误表明Action无法找到指定的工作目录路径。有趣的是，如果开发者预先执行了代码检出操作（这会触发.git方式而非GitHub API方式），或者手动创建了指定路径，问题就不会出现。

技术背景

tj-actions/changed-files提供了两种主要的工作方式：

1. Git本地仓库方式：需要预先检出代码库，通过分析.git目录来识别变更
2. GitHub API方式：直接通过GitHub的REST API获取变更信息，无需本地代码库

path参数的设计初衷是为了在Git本地仓库方式下，让开发者能够限定只检查特定子目录下的文件变更。这个参数会将工作目录切换到指定路径，然后在该相对路径下执行文件变更检测。

问题根源

GitHub API方式与path参数存在根本性的不兼容，原因在于：

1. GitHub API方式不需要也不使用本地工作目录，它完全通过远程API调用获取变更信息
2. path参数的设计假设存在本地工作目录结构，这在API方式下不成立
3. 当Action尝试切换工作目录到指定路径时，由于没有预先检出代码，该路径自然不存在

解决方案与变通方法

对于需要在GitHub API方式下限定特定子目录变更检测的场景，开发者可以采用以下方法：

1. 不使用path参数：直接在文件模式匹配中指定完整路径

   • 例如：使用apps/A/**/*.rb而非**/*.rb

2. 后处理变更列表：获取完整变更列表后，自行过滤出目标子目录的文件

   • 这需要开发者自行处理路径前缀的移除

3. 改用Git本地仓库方式：如果必须使用path参数，可以考虑预先检出代码库

   • 这会牺牲GitHub API方式的一些优势，如更快的执行速度

最佳实践建议

1. 明确区分使用场景：需要路径过滤时考虑使用Git本地仓库方式
2. 了解Action的限制：某些参数在特定工作模式下不可用是正常现象
3. 查阅文档：在使用前仔细阅读参数的适用条件和限制

理解这些技术细节有助于开发者在CI/CD流程中更有效地利用tj-actions/changed-files的强大功能，同时避免常见的配置陷阱。