Zizmor项目中发现的工作流文件识别缺陷分析

问题概述

在Zizmor项目的使用过程中，我们发现了一个关于GitHub Actions工作流文件识别的功能缺陷。当工作流文件(.yml)被放置在.github/workflows目录的子文件夹中时，Zizmor工具无法正确识别这些文件，导致分析不完整。

技术背景

Zizmor是一个用于分析GitHub Actions工作流的工具，它通常会扫描项目中的.github/workflows目录来查找需要分析的工作流文件。按照GitHub Actions的官方规范，工作流文件可以放置在.github/workflows目录及其子目录中，但Zizmor当前版本仅支持直接位于.github/workflows根目录下的文件。

问题重现

通过以下目录结构可以重现该问题：

.github/
└── workflows/
    ├── releases/
    │   └── workflow-release.yml
    └── workflow.yml

当用户执行zizmor .命令时，工具只会分析workflow.yml文件，而忽略releases/workflow-release.yml文件。这与预期行为不符，因为GitHub Actions本身支持这种嵌套目录结构。

影响范围

这个缺陷会影响以下使用场景：

1. 项目按照功能或类型将工作流文件分类到不同子目录中
2. 大型项目需要模块化管理多个工作流文件
3. 需要保持工作流文件组织结构的项目

技术分析

从技术实现角度看，问题可能出在文件扫描逻辑上。当前实现可能使用了简单的目录遍历方法，没有递归检查子目录中的文件。正确的实现应该：

1. 递归遍历.github/workflows目录及其所有子目录
2. 筛选出所有符合命名规则的YAML文件(.yml或.yaml)
3. 对所有找到的工作流文件进行分析

解决方案建议

修复此问题需要修改文件发现逻辑，建议采用以下方法：

1. 使用递归文件系统遍历算法
2. 添加对嵌套目录结构的支持
3. 保持与GitHub Actions相同的文件发现规则

总结

这个缺陷虽然不影响基本功能，但对于需要组织大量工作流文件的项目来说是一个重要限制。修复后将提高工具的兼容性和实用性，使其能够处理更复杂的工作流文件组织结构。对于用户而言，了解这一限制有助于在问题修复前合理组织工作流文件位置。