I'm using concurrency in my GitHub Actions to limit all workflows to one simultaneous run per workflow, per ref.

This ensures that only the latest push to a branch or pull request runs per workflow, saving both time and money.

This setup worked perfectly, until I tried using workflow_call. The issue arises because my concurrency group naming, which relies on ${{ github.workflow }}-${{ github.ref }}, doesn't work as expected with workflow_call events.

The problem is that ${{ github.workflow }} in the callee workflow inherits the name of the caller workflow (similar to how permissions work). This leads to a naming conflict, causing the callee to fail immediately. I can't seem to find a way to get the filename inside a workflow called by workflow_call, since according to the docs the callee inherits everything from the caller.

I need a solution that keeps the concurrency group label dynamic. ${{ github.workflow }} was ideal because workflow filenames are unique in the workflows folder, ensuring no accidental duplicates from other team members. I want to maintain this level of "idiot-proofing" while resolving the conflict with workflow_call.

Here is my setup:

deploy.web.yaml

name: "deploy / web"

on:
  workflow_dispatch:
  workflow_call:

concurrency:
  group: ${{ github.workflow }}-${{ 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

EXPECTED

The release.yaml workflow should call deploy.web.yaml successfully. If release.yaml is then called again while the previous call is still running it should cancel the oldest one and proceed with the newest.

REALITY

deploy.web.yaml fails immediately on the first call with this error:

Canceling since a deadlock for concurrency group 'release-refs/heads/main' was detected between 'top level workflow' and 'api'

NOTES

I am aware that I can just name the workflows hard coded, e.g. deploy-web-${{ github.ref }}, but this would go against the "idiot-proofing" I talked about before. Not to mention it would be very annoying having every concurrency group be dynamic except for the ones with workflow_call, which would always need to be hard coded.

I am also aware I can set the concurrency at the job level in the release.yaml workflow, like this:

jobs:
  web:
    concurrency:
      group: ${{ github.workflow }}-web-${{ github.ref }}
      cancel-in-progress: true
    uses: ./.github/workflows/deploy.web.yaml

This however, does not define concurrency at the workflow level and would mean If I were to call the workflow by another event, say workflow_dispatch, it would not have concurrency protection. Not to mention we also be hard coding the name for the group once again.

Hopefully there is a reasonable solution for this within the context of what I am looking for!