GitHub自托管Runner不可用时能否设置共享Runner作为备选？

可以实现，核心是在GitHub Actions Workflow中配置Runner备选逻辑，以下是两种实用方案：

方案一：优先级数组自动 fallback #

直接在runs-on字段中指定包含自托管Runner和共享Runner的标签数组，GitHub Actions会按顺序尝试分配Runner，当第一个不可用时自动切换到下一个。

示例Workflow代码：

jobs:
  ci-build:
    # 优先使用自托管Runner，不可用时切换到GitHub共享的Ubuntu Runner
    runs-on: [self-hosted, ubuntu-latest]
    steps:
      - name: 拉取代码
        uses: actions/checkout@v4
      # 后续CI步骤（如编译、测试等）

注：self-hosted是自托管Runner的默认标签，如果你给自托管Runner设置了自定义标签，替换成对应的标签即可；ubuntu-latest是共享Runner的标签，也可以根据需求换成windows-latest或macos-latest。

方案二：自定义检测逻辑切换 #

如果需要更灵活的控制（比如提前检测自托管Runner状态再决定），可以结合脚本检测和条件表达式实现：

示例Workflow代码：

jobs:
  ci-build:
    runs-on: ${{ env.USE_SELF_HOSTED == 'true' ? 'self-hosted' : 'ubuntu-latest' }}
    steps:
      - name: 检测自托管Runner可用性
        id: check-runner
        run: |
          # 这里可以添加自定义检测逻辑，比如调用GitHub API检查Runner在线状态
          # 示例：假设检测后发现自托管Runner不可用，设置环境变量
          echo "USE_SELF_HOSTED=false" >> $GITHUB_ENV
      - name: 执行CI任务
        run: |
          # 你的CI执行命令

注意事项 #

• 私有仓库需要确认当前GitHub计划允许使用共享Runner（公开仓库默认支持）。
• 自托管Runner和共享Runner的环境可能存在差异（如依赖版本、系统配置），需确保CI步骤在两种环境下都能正常运行，或针对不同Runner添加适配逻辑。
• 可以通过timeout-minutes字段设置作业超时时间，避免无意义的等待。

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