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

2. Use the action in a workflow:

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

3. 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)

[nathanblair]

The documentation here should also reflect the special behavior mentioned at the top of the page. Probably more importantly in the section more explicitly dedicated to with.

[maxsxu]

The issue still exists but thanks to the above workaround, which works.

Wondering any updates or plans on this?

[diepes]

I seem to have stumbled on another corner case in an action.

The inputs.xyz seem to disappear after a step that uses a with:, they (inputs.) are no longer available for other steps.

ci.yaml. (steps: uses action1 passing inputs in with:)
action1.yaml ( halfway through uses action2 passing inputs in with:)
after this step in action1.yaml all the input.xyz seem to be empty.

Work around by adding all to env.
echo "password=${{ inputs.password }}" |tee -a $GITHUB_ENV

[perj]

Note that Github recommends to not use ${{ inputs.x }} directly in shell scripts, due to quoting issues.
It's better to always first set them to environment variables. Why not one called INPUT_x such that if this is ever fixed that is the same variable name...

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#example-of-a-script-injection-attack

[y-nk]

there's an issue with this, is that we can't use @actions/core's getInput because it relies on process.env.INPUT_xxx to function.

https://github.com/actions/toolkit/blob/1b5a6e26f42769414fe2302e6a6e8b5ac7bf9600/packages/core/src/core.ts#L126-L138

For people interested in fixing the above, an easy fix is to manually provide the env var such as:

env:
  INPUT_FOO: ${{ inputs.foo }}

it's not ideal, but i'll fix the glue with what's expected from @actions/github-script