如何从上游GitHub Action工作流触发调度下游工作流延迟执行

GitHub Actions原生支持上游工作流触发下游工作流，你当前使用的workflow_run触发规则是官方提供的原生跨工作流触发能力，但你目前的实现存在明显缺陷，有稳定性更高、成本更低的实现方式。

现有方案的核心问题 #

你当前在WorkFlowTwo的执行步骤中直接通过sleep 1h空等1小时再执行停服逻辑，存在三个不可控的风险：

• 空跑sleep会全程占用GitHub Actions运行器资源，白白消耗运行分钟配额，私有仓库场景下会产生不必要的计费成本
• 空等的1小时内如果遇到运行器故障、网络波动导致Job意外退出，后续的停服逻辑会直接中断，造成Grid服务器资源残留无法回收
• 触发规则配置的是completed，意味着上游WorkFlowOne不管执行成功、失败还是被取消，都会触发下游停服流程，很容易出现测试还没正常启动就被提前停服的问题；如果短时间内多次触发上游工作流，还会并行启动多个下游停服任务，逻辑冲突概率很高。

优先推荐的优化方案 #

方案一：单工作流内实现全链路逻辑（同仓库场景首选） #

不需要拆分两个独立工作流，直接在WorkFlowOne中新增独立的资源回收Job，通过依赖关系控制执行顺序，避免跨工作流触发的额外复杂度：

name: WorkFlowOne
on:
  workflow_dispatch:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

# 配置并发规则，避免同时运行多个工作流实例导致启停冲突
concurrency: grid_test_environment

jobs:
  start_grid:
    name: Start Grid
    runs-on: ubuntu-latest
    steps:
      - name: Get Token
        run: ...
      - name: Start Grid
        run: ./startGrid.sh 

  run_test:
    name: Run Test
    runs-on: ubuntu-latest
    needs: start_grid
    steps:
      - name: invoke test
        run: |
           sleep 5m 10s
           startTest.sh

  terminate_grid:
    name: Terminate Grid
    runs-on: ubuntu-latest
    # 等测试任务执行完再启动回收任务
    needs: run_test
    # 无论测试成功、失败还是被取消，都执行资源回收，避免残留
    if: ${{ always() }}
    steps:
      - name: Wait 1 hour before termination
        # 用支持API轮询的延迟Action实现等待，不需要运行器空跑sleep
        uses: wait-action@v2
        with:
          milliseconds: 3600000
      - name: Stop Grid
        run: ./stopGrid.sh

这个方案的优势：

• 所有逻辑集中在单个工作流内维护，依赖关系清晰，不需要处理跨工作流的事件传递问题
• 延迟等待通过API轮询实现，不会占用运行器计算资源空等，不会浪费Action配额
• 加了并发控制和always()判断，从根源上避免多实例冲突、资源残留的问题。

方案二：保留双工作流结构的优化方案 #

如果你确实需要把停服逻辑拆分到独立工作流维护，可以对现有配置做两处核心修改：

1. 把workflow_run的触发类型从completed改成success，只有上游WorkFlowOne完全执行成功才触发下游流程，避免异常状态下的无效触发
2. 去掉Job内的长sleep，改成调度逻辑：当前Job只负责注册1小时后的停服任务，调度完成就直接退出，不需要空等，时间到了再触发实际的停服逻辑。
   修改后的WorkFlowTwo参考配置：

name: WorkFlowTwo
on:
  workflow_run:
    workflows: [ "WorkFlowOne" ]
    branches: [ main ]
    types: [ success ]
  workflow_dispatch:
  repository_dispatch:
    types: [ delayed_stop_grid ]

concurrency: grid_termination_task
    
jobs:
  schedule_terminate:
    name: Schedule Grid Termination
    runs-on: ubuntu-latest
    if: ${{ github.event_name == 'workflow_run' || github.event_name == 'workflow_dispatch' }}
    steps:
      - name: Register delayed stop task
        run: |
          # 调用GitHub接口派发1小时后执行的仓库事件，触发停服任务
          gh api repos/${{ github.repository }}/dispatches \
            -f event_type=delayed_stop_grid \
            --field 'client_payload={"scheduled_time": ${{ github.event.head_commit.timestamp }} }'
          # 调度完成直接结束当前Job，不需要等待

  terminate_grid:
    name: Terminate Grid
    runs-on: ubuntu-latest
    if: ${{ github.event_name == 'repository_dispatch' }}
    steps:
      - name: Stop Grid
        run: ./stopGrid.sh

如果你的Grid服务本身支持传入延迟关停参数，也可以在调度步骤直接调用Grid的延迟停服接口，完全不需要依赖GitHub侧的等待逻辑，稳定性会更高。

通用注意事项 #

• 永远不要在CI Job里写超过5分钟的sleep空等，等待时间越长，Job因为运行器故障、网络问题中断的概率越高，且会产生不必要的资源浪费
• 涉及测试环境启停的场景一定要加并发控制，避免多个流水线同时操作同一套环境导致逻辑混乱
• 如果需要超过6小时的长延迟，不要依赖GitHub Action的Job内等待，可以直接用平台侧的定时任务能力触发停服逻辑。

内容的提问来源于stack exchange，提问作者Samit Kumar Patel