GitHub Actions中workflow_call调用时并发组如何使用工作流文件名

问题根源 #

当通过workflow_call调用子工作流时，子工作流中的${{ github.workflow }}会继承父工作流的名称，导致子工作流的并发组与父工作流完全一致。父工作流持有该并发组的锁后，子工作流再请求同一锁就会触发死锁检测，最终被GitHub Actions取消。

核心思路 #

放弃依赖github.workflow，改用工作流文件的唯一标识（如文件路径或文件名）作为并发组的基础。该标识在子工作流被直接触发或被调用时，始终指向子工作流自身的文件，不会被父工作流覆盖，既保留了动态命名的防误操作特性，又避免了冲突。

修改后的配置示例 #

子工作流：deploy.web.yaml #

name: "deploy / web"

on:
  workflow_dispatch:
  workflow_call:

# 用工作流文件的文件名作为唯一标识，避免继承父工作流名称
concurrency:
  group: ${{ last(split(github.workflow_file, '/')) }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  staging:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Web deployment to staging not configured yet"

父工作流：release.yaml（无需修改，保持原有逻辑） #

name: "release"

on:
  push:
    branches: [main]

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  metadata:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
  web:
    needs: [metadata]
    uses: ./.github/workflows/deploy.web.yaml

方案优势 #

1. 无硬编码维护成本：并发组名称自动关联工作流文件，文件名变更时无需手动修改并发组配置，保留了「防误操作」特性
2. 兼容两种触发场景：
   • 直接通过workflow_dispatch触发子工作流时，并发组为deploy.web.yaml-${ref}，正常限制同一分支/PR的并发运行
   • 被父工作流调用时，子工作流并发组仍为自身文件标识，与父工作流的release-${ref}无冲突，彻底解决死锁问题
3. 符合预期行为：父工作流重复触发时，旧实例会被取消，新实例的子工作流也能正常执行

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