子模块仓库变更时自动运行主仓库工作流的实现方案咨询

以下是三种不同适用场景的可行实现方案：

• 方案1：子模块仓库配置触发逻辑（实时性最高，最常用）
  给主仓库生成一个拥有workflow触发权限的个人访问令牌(PAT)，将该令牌存到所有子模块仓库的保密变量(Secrets)中。在每个子模块的CI配置里添加监听push事件的步骤，事件触发时调用主仓库的工作流触发接口即可。
  以GitHub Actions为例，子模块的CI配置添加如下步骤：

  - name: 触发主仓库工作流
    uses: actions/github-script@v6
    with:
      github-token: ${{ secrets.MAIN_REPO_TRIGGER_TOKEN }}
      script: |
        await github.rest.actions.createWorkflowDispatch({
          owner: "主仓库所属用户名/组织名",
          repo: "主仓库名称",
          workflow_id: "要触发的主仓库工作流文件名.yml",
          ref: "主仓库运行工作流的目标分支，如main"
        })
  

  其他CI平台（GitLab CI、Jenkins等）逻辑一致，直接调用对应平台的主仓库工作流触发API即可。

• 方案2：主仓库定时巡检更新（适合无法修改子模块配置的场景）
  在主仓库配置定时触发的工作流，定期拉取所有子模块的最新提交哈希，和当前主仓库记录的子模块版本对比，只要存在差异就自动触发目标工作流。
  以GitHub Actions为例，定时触发的配置示例如下：

  on:
    schedule:
      # 每小时巡检一次，可按需调整执行频率
      - cron: "0 * * * *"
  

  该方案存在触发延迟，适合对实时性要求不高的场景。

• 方案3：组织级全局监听（适合子模块数量多的场景）
  如果所有子模块和主仓库归属同一个组织/企业账号，可以直接在组织层级配置全局webhook，监听所有子模块的push事件，事件触发时统一调用主仓库的工作流触发接口，不需要逐个修改子模块的CI配置，运维成本更低。

注意事项 #

• 触发主仓库工作流时可以传递变更的子模块名称、提交哈希等参数，让主仓库工作流仅执行对应子模块相关的任务，减少不必要的资源消耗
• 注意规避循环触发问题：如果主仓库工作流运行时会回写内容到子模块，需要添加过滤规则，排除CI账号发起的提交，避免出现无限触发的死循环
• 用到的访问令牌需要做最小权限配置，仅开放工作流触发的必要权限即可，不要额外开仓库读写等高权限

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