How do you identify the trigger action that's coming from Workflow Call?

[isdzulqor]

I cannot use this code check if: github.event_name == 'workflow_call' to ensure that the trigger is coming from workflow_call. It's working ok with 'workflow_dispatch' even though.

My triggering action is like the following code

on:
  pull_request:
    paths-ignore:
      - "Makefile"
      - '**.md'
      - 'docs/**'
    branches: [master]
  # Trigger called from dev_deploy_services.yml & prod_deploy_services.yml
  workflow_call:
    inputs:
      checkout-ref:
        type: string
        required: true
    secrets:
      github-token:
        required: true
      slack-webhook:
        required: true

My question is How do you identify The trigger action that's coming from Workflow Call?

[gaurav-mehta-mcd]

Any reply on this Question ? @isdzulqor your Issue got resolved?

[isdzulqor]

@isdzulqor your Issue got resolved?

Nope as of my latest check.

[kenorb]

It's surprising that there are no straight-forward solutions to this.

[msquantori]

I believe I have similar issue. Even when the workflow is called, github.event_name is set to 'workflow_dispatch' for a some reason, I expect it to be workflow_call

[kenorb]

Related: GH-3146.

[deitry]

In my action I decided to go with fake input which is present only in workflow_call

on:
  workflow_call:
    inputs:
      externalCall:
        description: 'To distinguish workflow_call from regular push'
        type: boolean
        required: false
        default: true

...
  # runned only from workflow_call
  - if: ${{ inputs.externall_call }}

It has default value so I do not have to specify it manually each time I want to use it

[becheran]

Small typo here I guess. It should be externall_call instead of externalCall I guess? Otherwise ${{ inputs.externall_call }} uses an unknown input.

[kenorb]

One issue with that solution is that inputs won't exist when you call that workflow locally (e.g. on push), generating errors about inputs being undefined.

[RomanBredehoft]

I also faced the exact same issue and it's pretty inconvenient as my workflow has both a workflow_dispatch and workflow_call trigger !

I initially thought that the problem was lying in the fact that the caller workflow was triggered using workflow_dispatch (and that github.event_name might be somewhat global or is not properly updated), but I can't find any more information that supports that.

In any case, I followed @deitry's suggestion (many thanks !) and used :

      manual_call:
        description: 'To distinguish workflow_call from workflow_dispatch'
        type: boolean
        required: false
        default: true

with default: true for worfkow_dispatch and default: false for workflow_call. It works great but it's definitively not ideal !

[colin-rogers-dbt]

Running into this as well, I wonder if the event_name gets inherited from the calling workflow

[btrautmann]

Just ran into this myself :) Going to use the approach described above but it's 100% surprising when you run into it.

[elijaholmos]

Running into this as well... why even include a "workflow_call" trigger if it won't be reflected in the github.event_name?

[kenorb]

See: GH-3146.

[dcacaceshopfully]

Same problem, when the workflow is called by another one I receive as event push, as it was inherited

[boholder]

Be aware that if your caller workflow is triggered by workflow_dispatch, your reused workflow's github.event_name will also be workflow_dispatch instead of workflow_call, for example in action execution below, build workflow's Upload Mod Files To Artifact step is executed by this reason: https://github.com/boholder/minecraft-access/actions/runs/7634666443/job/20799033613

[ktomaszx]

also had the same problem, and my workaround is using github.event.workflow
if github.event.workflow equals current workflow (eg. .github/workflows/test.yml) it means that it was triggered manually
but if it equals to something different it had to be triggered by another workflow

[kenorb]

Are you sure? github.event.workflow is null. There is no such thing as workflow as per https://docs.github.com/en/rest/using-the-rest-api/github-event-types.

[kenorb]

If you're calling the workflow from another repository, one way is to hardcode its repository name, e.g.

env:
  REPOSITORY: org/myrepo

on:
  workflow_call:

jobs:
  myjob:
    runs-on: ubuntu-latest
    steps:
      - if: github.repository == env.REPOSITORY
        uses: some/thing

Or add extra an input as mentioned in the other answers.

Here is proposed workaround using inputs:

env:
  SKIP_CLEANUP: ${{ inputs.skip_cleanup || false }}
# yamllint disable-line rule:truthy
on:
  workflow_call:
    inputs:
      skip_cleanup:
        default: false
        description: Whether to skip a clean-up job.
        required: false
        type: boolean
jobs:
  cleanup:
    if: inputs.skip_cleanup != true
    name: Clean-up
    runs-on: ubuntu-latest
    steps:
      - uses: geekyeggo/delete-artifact@v5
        with:
          name: *

Then from the caller job run as:

jobs:
  caller:
    uses: ./.github/workflows/test.yml
    with:
      skip_cleanup: true

Above is based on the comments at GH-3146.