Hopefully reusable workflow agrees to support ${{inputs. XXX}} expression parameter passing

Describe the enhancement I wanted to pass the parameters of the workflow_dispatch input in a reusable workflow, and with ${{inputs.username}} expression, the value could not be read and without an error message.

But if using ${{github.event.inputs.username}} it works fine, I don’t know why. The official documentation does not detail the difference between the two and which to use in reusable workflows

Code Snippet

name: Caller

on:
  workflow_dispatch:
    inputs:
      username:
        type: string
        description: 'username'
        required: false
        default: 'john-doe'
        
jobs:
  Test-1:
      uses: ./.github/workflows/test_1.yml
      with:
        username: ${{ inputs.username }}       #${{ github.event.inputs.username }}
      secrets: inherit

name: Executor

on:
  push:
  workflow_call:
    inputs:
      username:
        type: string
        description: 'A username passed from the caller workflow'
        default: 'john-doe'
        required: false
        
      
jobs:
  Test-1:
    runs-on: ubuntu-latest
    steps:
      - name: Print the input name to STDOUT
        run: echo The username is ${{ inputs.username }}

Additional information Add any other context about the feature here.

NOTE: if the feature request has been agreed upon then the assignee will create an ADR. See docs/adrs/README.md

[nathanchapman]

Same here ☝️

I’m filing a bug report with our GitHub Enterprise Cloud support. Here are some more details and examples for anyone interested.

Now that inputs have been unified across manual and reusable workflows, we’ve moved to using the inputs context across all workflow files. However, as of the last week or so, we’ve noticed a transparent change where the inputs context is broken within reusable workflows when those values are computed from inputs to the dispatched workflow. In other words, the reusable workflow’s inputs context is trampled and/or muddied by the dispatched workflow’s inputs context, depending on how inputs are passed.

Example 1

In this example, we’re just setting up the workflow files.

name: Dispatchable Workflow

on:
  workflow_dispatch:
    inputs:
      gitRef:
        type: string
        description: The branch, tag, or SHA to checkout
        required: false

jobs:
  tests:
    name: Tests
    uses: ./.github/workflows/tests.yml
    with:
      gitRef: hardcoded
      otherInput: hardcoded
    secrets: inherit

name: Tests

on:
  workflow_call:
    inputs:
      gitRef:
        type: string
        description: The branch, tag, or SHA to test
        required: true
      otherInput:
        type: string
        description: Input only for example
        required: true

jobs:
  unitTests:
    name: Unit Tests
    runs-on: ubuntu-latest

    steps:
      - name: Debug Inputs
        run: echo "${{ toJSON(inputs) }}"

Running this workflow, whether a value is set for gitRef or not, results in the following expected output:

{
  gitRef: hardcoded,
  otherInput: hardcoded
}

Example 2

The reusable workflow remains the same, but we’ve modified how it’s being called (with the inputs context):

name: Dispatchable Workflow

on:
  workflow_dispatch:
    inputs:
      gitRef:
        type: string
        description: The branch, tag, or SHA to checkout
        required: false

jobs:
  tests:
    name: Tests
    uses: ./.github/workflows/tests.yml
    with:
      gitRef: ${{ inputs.gitRef }}
      otherInput: hardcoded
    secrets: inherit

results in the following when example is passed as the gitRef to the dispatchable workflow:

{
  gitRef: ,
  otherInput: hardcoded
}

Example 3

The previous example looks like a possible name clash, so let’s modify our dispatchable workflow even further to avoid a possible clash:

name: Dispatchable Workflow

on:
  workflow_dispatch:
    inputs:
      checkoutRef:
        type: string
        description: The branch, tag, or SHA to checkout
        required: false

jobs:
  tests:
    name: Tests
    uses: ./.github/workflows/tests.yml
    with:
      gitRef: ${{ inputs.checkoutRef || 'master' }}
      otherInput: hardcoded
    secrets: inherit

results in the following when example is passed as the checkoutRef to the dispatchable workflow:

{
  checkoutRef: example,
  gitRef: master,
  otherInput: hardcoded
}

Still not what we’re expecting as output within the reusable Tests workflow. I’d expect:

{
  gitRef: example,
  otherInput: hardcoded
}

It appears that inputs.checkoutRef was not properly evaluated when setting the value for gitRef and somehow both fields ended up getting passed to the reusable workflow.

Example 4

Now, let’s switch from using the inputs context to using github.event.inputs within the dispatchable workflow. Again, nothing has changed in the reusable Tests workflow since the beginning.

name: Dispatchable Workflow

on:
  workflow_dispatch:
    inputs:
      checkoutRef:
        type: string
        description: The branch, tag, or SHA to checkout
        required: false

jobs:
  tests:
    name: Tests
    uses: ./.github/workflows/tests.yml
    with:
      gitRef: ${{ github.event.inputs.checkoutRef || 'master' }}
      otherInput: hardcoded
    secrets: inherit

results in the following when example is passed as the checkoutRef to the dispatchable workflow:

{
  checkoutRef: example,
  gitRef: example,
  otherInput: hardcoded
}

this finally gives us the correct behavior in gitRef, but again, still doesn’t quite match the inputs context I’d expect within the reusable Tests workflow, given that we’re providing inputs explicitly with the with keyword. Expected output:

{
  gitRef: example,
  otherInput: hardcoded
}

Example 5

In this example, we’re unifying the names of the inputs once again.

name: Dispatchable Workflow

on:
  workflow_dispatch:
    inputs:
      gitRef:
        type: string
        description: The branch, tag, or SHA to checkout
        required: false

jobs:
  tests:
    name: Tests
    uses: ./.github/workflows/tests.yml
    with:
      gitRef: ${{ github.event.inputs.gitRef || 'master' }}
      otherInput: hardcoded
    secrets: inherit

results in the following when example is passed as the gitRef to the dispatchable workflow:

{
  gitRef: example,
  otherInput: hardcoded
}

and the following when nothing is passed as the gitRef to the dispatchable workflow:

{
  gitRef: master,
  otherInput: hardcoded
}

This is close to the correct behavior. It allows computation (namely, default / fallback values) and the inputs context is correct within the reusable Tests workflow.

However, it’s only not “muddied” because the input names match. Any additional inputs added to the dispatchable workflow end up in the inputs context for the reusable workflow even though they’re not explicitly passed (muddying). If the reusable workflow has an input name that matches an input name from the dispatchable workflow, we end up with an empty / nullish value in the inputs context within the reusable workflow (trampling).

Requested Change

The inputs context is scoped to the appropriate workflow and inputs into reusable workflows can be computed from inputs into dispatched workflows.

[ajaykn]

We have noticed this regression and waiting for the fix to be rolled out. Apologies for the inconvenience 😦

cc @genieCS