GitHub Workflow中Dependabot自动合并的Secret调用失败问题

核心排查与修复步骤 #

• 先核对Secret名称：你说创建的仓库Secret叫MY_SECRET，但Workflow里用的是${{ secrets.MY_TOKEN }}，名称完全不匹配！立刻把引用改成${{ secrets.MY_SECRET }}，这是最容易踩的低级错误。
• 检查PAT权限：你的个人访问令牌（PAT）必须勾选repo权限（私有仓库必填），还要确保包含操作PR的权限，别漏勾权限选项导致凭证无效。
• 验证可重用Workflow的传参逻辑：如果用了可重用Workflow，必须在调用时显式传递Secret，分两种情况：
  • 若可重用Workflow用inputs接收token：

    jobs:
      auto-merge:
        uses: owner/repo/.github/workflows/auto-merge.yml@main
        with:
          token: ${{ secrets.MY_SECRET }}
    

  • 若可重用Workflow用secrets接收：

    jobs:
      auto-merge:
        uses: owner/repo/.github/workflows/auto-merge.yml@main
        secrets:
          PAT_TOKEN: ${{ secrets.MY_SECRET }}
    

  同时要确认被调用的可重用Workflow里的定义，比如：

  # 可重用Workflow的头部定义
  inputs:
    token:
      required: true
      type: string
  # 或者用secrets的方式
  secrets:
    PAT_TOKEN:
      required: true
  

• 查看Workflow执行日志：去仓库Actions页面找到失败的运行记录，展开auto-merge任务的日志，看具体错误上下文——有时候"Input required"提示的是可重用Workflow的必填参数没传，不是Secret本身的问题。
• 测试Secret是否能被读取：临时加一个测试步骤，输出Secret的长度（避免泄露明文），验证是否能正常获取：

  steps:
    - name: 验证Secret访问权限
      run: echo "Secret长度: ${#INPUT_SECRET}"
      env:
        INPUT_SECRET: ${{ secrets.MY_SECRET }}
  

  如果输出长度为0，说明Secret没传进来，检查是否是仓库级Secret（别搞成组织级或环境级，除非Workflow指定了对应环境）。

额外注意坑点 #

• 环境级Secret需要在Workflow的job里指定environment字段才能访问，比如：

  jobs:
    auto-merge:
      environment: production
      steps:
        # 此处才能访问该环境的Secret
  

• Dependabot触发的Workflow，默认的GITHUB_TOKEN权限不足，必须用你自己创建的PAT，这点你已经做了，但要确认PAT没过期。

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