如何自动推送新版本至调用集中式GitHub工作流的所有仓库？

我在组织的集中式仓库里开发GitHub工作流，供其他应用团队的仓库调用。这些调用仓库都有main.yml（处理push动作）和pull-request.yml（处理拉取请求动作），调用格式如下：

jobs:
  call-workflow:
    uses: octo-org/example-repo/.github/workflows/workflow-A.yml@v1

其中example-repo包含名为v1的release标签。我想找一种自动化方式，给这些调用仓库开PR来更新工作流的新版本和修复版本。我设想的步骤是：

• 以release标签创建作为触发事件
• 遍历组织内所有仓库
• 检查是否存在.github/workflows目录（不是所有仓库都在用我们的工作流）
• 如果存在，检查是否有对我们工作流的调用
• 如果工作流的tag-ref需要更新，就打开PR

请问这个方案可行吗？有没有更优的方案？我原本想设置组织级的$RELEASE_VERSION变量，但这类变量好像没法在工作流调用时解析，有什么解决思路吗？

方案可行性 #

你设想的方案完全可行，这是维护共享工作流版本的常规思路之一，核心逻辑清晰且覆盖了关键校验环节，能有效筛选出需要更新的仓库并自动化发起PR。

更优方案建议 #

• 缩小遍历范围：不用遍历组织内所有仓库，而是维护一个使用共享工作流的仓库清单（比如在集中式仓库里建一个repos-list.yml配置文件），只针对清单内的仓库操作。这样能减少不必要的API调用，提升效率，还能避免误触不相关仓库。
• 分版本策略处理：如果你的共享工作流有不同分支（比如main对应稳定版，dev对应开发版），可以在触发事件里区分：创建正式release标签时更新稳定版引用，推送dev分支时更新开发版引用，更贴合不同团队的迭代节奏。
• PR内容增强：在自动生成的PR里添加更新说明（比如本次共享工作流的修复点、新特性），关联对应的release信息，方便团队快速了解更新内容，提升PR合并率。
• 使用GitHub App替代个人令牌：如果用GitHub Actions执行自动化，建议用GitHub App获取权限，比个人访问令牌更安全，权限也更易管控，适合跨仓库操作场景。

组织级变量无法解析的解决思路 #

GitHub确实不支持在uses字段里直接引用组织/仓库级变量，因为uses的解析是在工作流运行前完成的，此时变量还未被注入。可以试试这几种方案：

• 分支别名替代固定标签：比如把最新稳定版的标签同步到stable分支，调用时写成@stable，每次发布新版本时，只需要把stable分支指向新的标签即可。调用仓库不需要修改配置就能自动使用最新稳定版，但缺点是无法固定版本，适合对版本兼容性要求高、能快速跟进更新的团队。
• 回到自动化PR方案：这其实是最稳妥的方式——通过自动化PR把调用里的标签更新到最新版本，既能让团队自主选择是否合并（保留版本控制权），又能统一推送更新，兼顾灵活性和一致性。
• 动态生成工作流文件（不推荐）：在调用仓库的工作流里，先通过一个步骤生成临时的工作流配置，把变量替换成实际的版本号，再执行这个临时工作流。这种方式会增加调用仓库的配置复杂度，仅适合特殊场景。

内容的提问来源于stack exchange，提问作者stillmaticone17