Runner: INPUT_* environment variables are missing in composite actions

[airtower-luna]

According to the documentation actions should receive their input values as environment variables prefixed with INPUT_ in addition to the inputs context. These environment variables are missing for composite actions.

To Reproduce
Steps to reproduce the behavior:

1. Create a composite action with one or more inputs, and a step that outputs the associated INPUT variables:

inputs:
  foo:
    description: 'Test input'
    required: yes
runs:
  using: composite
  steps:
    - run: |
        echo "FOO: ${INPUT_FOO}"
      shell: bash

1. Use the action in a workflow:

steps:
  - uses: ./example-action
    with:
      foo: 'bar'

1. Observe the lack of value after the FOO: prefix.

I have an example action and workflow (the uses: ./composite-action step) that demonstrate the issue and the obvious workaround. There's a workflow run as well (check the "Run /./composite-action" step).

Expected behavior
Steps should be able to read inputs via environment variables, INPUT_FOO in the example above, INPUT_NUM1 (to 4) in my reproducer.

Runner Version and Platform

Version of your runner?

• 2.272.0

OS of the machine running the runner? OSX/Windows/Linux/...

• Ubuntu 20.04.1 LTS (Github hosted runner VM)

Job Log Output

From the workflow run linked above:

Run ./composite-action
  with:
    num1: 1
    num2: 4
    num3: 0
    num4: 0
Show INPUT vars
  INPUT_NUM1 = 
  INPUT_NUM2 = 
  INPUT_NUM3 = 
  INPUT_NUM4 = 
Add numbers

Credit

I became aware of the issue thanks to a post on the Github community forum and tried to reproduce the issue out of curiosity.

[ericsciple]

When authoring a composite action, inputs must be mapped into inner steps using GitHub Actions expressions.

For example, map into the script directly:

inputs:
  foo:
    description: 'Test input'
    required: yes
runs:
  using: composite
  steps:
    - run: |
        echo "FOO: ${{inputs.foo}}"
      shell: bash

Or for example, map into the script indirectly via env var:

inputs:
  foo:
    description: 'Test input'
    required: yes
runs:
  using: composite
  steps:
    - run: |
        echo "FOO: $MY_VAR"
      shell: bash
      env:
        MY_VAR: ${{ inputs.foo }}

[ericsciple]

We need to update the referenced doc

[airtower-luna]

Fair enough, but wouldn't it be simpler to have the same behavior across all kinds of actions? Or is there a technical reason not to provide the INPUT_ environment variables?

[amis92]

I've hit that as well.

After some thought I imagine it's because if, in future, they enable composite steps to contain other uses actions (not just shell runs), this would cause confusion in those sub-actions which inputs are theirs, and which are the parent composite action's.

Better documentation definitely will help there. :) edit I think it's also important to include the inputs context in the Contexts documentation, because currently it's not there.

[thepwagner]

👋 I've been using a workaround like _ericsciple's:
inputs: branches: description: 'Branches to update' required: false runs: using: "composite" steps: - run: my-awesome-action.sh shell: bash env: INPUT_BRANCHES: ${{ inputs.branches }}

I want to map the variable as INPUT_BRANCHES so I can reuse getInput() from the Actions SDK in my implementation.
Using ${{input.branches}} directly in the command doesn't work (Actions SDK can't find it).

I'd dig a way to say "please forward ALL my action.yml:inputs to this step" without mapping every key. env: actionInputs(), actionInputs: true?
Forwarding them without special configuration is 👍 too, but changing the exposure of existing composite actions is, as noted, bad.

(I wound up here after adding an input and forgetting about needing this hack to forward it. ~10% of my current action.yaml is input forwarding boilerplate)