如何通过Github Actions实现两个关联仓库的通信与部署协作？

核心架构逻辑 #

Repo A作为需求触发源，仅维护业务功能代码；Repo B作为部署控制中心，维护所有云平台的部署脚本、参数配置。两者通过GitHub Actions的事件触发+API调用完成闭环协作。

具体实现步骤 #

1. 配置跨仓库访问权限 #

• 在Repo B的Settings → Secrets and variables → Actions中，创建一个具有Repo A读写权限的GitHub Personal Access Token（PAT），权限至少勾选repo、workflow。
• 在Repo A的对应位置，同样创建一个能触发Repo B workflow的PAT，权限勾选repo。

2. Repo A触发部署需求 #

在Repo A的.github/workflows/trigger-deploy.yml中编写触发逻辑，当满足条件（比如tag推送、PR合并）时，调用Repo B的workflow：

name: Trigger Deployment to Repo B
on:
  push:
    tags:
      - 'v*' # 示例：打tag时触发
  workflow_dispatch: # 支持手动触发

jobs:
  trigger-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Call Repo B's deploy workflow
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.REPO_B_PAT }}
          script: |
            await github.rest.actions.createWorkflowDispatch({
              owner: '你的GitHub用户名',
              repo: 'RepoB',
              workflow_id: 'deploy.yml',
              ref: 'main',
              inputs: {
                repo_a_ref: '${{ github.ref }}',
                repo_a_sha: '${{ github.sha }}',
                deploy_env: 'production' // 可根据需求传递自定义参数
              }
            })

这里通过createWorkflowDispatch触发Repo B的指定workflow，同时传递Repo A的代码版本、部署环境等关键参数，确保Repo B能精准定位需求。

3. Repo B接收需求并执行部署 #

在Repo B的.github/workflows/deploy.yml中编写部署逻辑，接收Repo A传递的参数，执行对应云平台的部署操作：

name: Execute Deployment
on:
  workflow_dispatch:
    inputs:
      repo_a_ref:
        description: 'Repo A的代码分支/标签'
        required: true
      repo_a_sha:
        description: 'Repo A的提交SHA'
        required: true
      deploy_env:
        description: '部署环境'
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo A code
        uses: actions/checkout@v4
        with:
          repository: '你的GitHub用户名/RepoA'
          ref: ${{ github.event.inputs.repo_a_sha }}
          token: ${{ secrets.REPO_A_PAT }}

      - name: Setup AWS credentials（示例AWS部署）
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Execute deployment script
        run: |
          # 这里写你的部署逻辑，比如Terraform部署、容器镜像构建推送等
          ./deploy-scripts/${{ github.event.inputs.deploy_env }}.sh

      - name: Notify deployment result to Repo A
        if: always()
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.REPO_A_PAT }}
          script: |
            const status = '${{ job.status }}'
            await github.rest.issues.create({
              owner: '你的GitHub用户名',
              repo: 'RepoA',
              title: `Deployment Result: ${status} for ${context.payload.inputs.repo_a_ref}`,
              body: `
              Deployment Details:
              - Repo A SHA: ${context.payload.inputs.repo_a_sha}
              - Environment: ${context.payload.inputs.deploy_env}
              - Status: ${status}
              `
            })

关键说明：

• 通过workflow_dispatch定义输入参数，接收Repo A传递的信息；
• 拉取Repo A指定版本的代码，结合自身的部署脚本执行操作；
• 用if: always()确保无论部署成功/失败都会触发结果通知，通过GitHub API在Repo A中创建Issue反馈结果（也可以用评论PR、触发Repo A的workflow等方式）。

4. 可选：优化结果反馈方式 #

如果不想用Issue，也可以触发Repo A的专用结果处理workflow：
在Repo B的通知步骤替换为：

await github.rest.actions.createWorkflowDispatch({
  owner: '你的GitHub用户名',
  repo: 'RepoA',
  workflow_id: 'handle-deploy-result.yml',
  ref: 'main',
  inputs: {
    deploy_status: '${{ job.status }}',
    repo_a_sha: '${{ github.event.inputs.repo_a_sha }}',
    deploy_env: '${{ github.event.inputs.deploy_env }}'
  }
})

然后在Repo A中编写handle-deploy-result.yml，根据结果执行测试、通知团队等操作。

规范与最佳实践 #

• 参数校验：在Repo B的workflow中添加参数校验步骤，避免无效的部署请求；
• 日志留存：在两个仓库的workflow中都开启完整日志记录，便于排查问题；
• 权限最小化：创建PAT时只赋予必要权限，避免过度授权；
• 环境隔离：针对不同部署环境（dev/staging/prod）维护独立的部署脚本和参数；
• 重试机制：在部署步骤中添加失败重试逻辑，提升稳定性。

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