Composite action inputs inside a shell script #27088

38ri581oq480 · 2021-06-14T10:11:44Z

38ri581oq480
Jun 14, 2021

Hello!
How can I access composite action inputs inside a shell script?

${{ inputs.input_name }}

and

$INPUT_INPUT_NAME

not working inside a shell script!

For example:
action.yml

inputs:
  test_input:
    name: "Test input"
runs:
  using: 'composite'
  steps:
    - run: ${{ github.action_path }}/entrypoint.sh
      shell: bash

entrypoint.sh

echo ${{ inputs.test_input }} 
echo $INPUT_TEST_INPUT

Answered by airtower-luna

Jun 14, 2021

I’ve had that issue, too, unfortunately the bug report is still unresolved:

  <a href="https://github.com/actions/runner/issues/665" target="_blank" rel="noopener">github.com/actions/runner</a>

INPUT_* environment variables are missing in composite actions

<div class="github-info">
  <div class="date">
    opened <span class="discourse-local-date" data-format="ll" data-date="2020-08-17" data-time="20:54:00" data-timezone="UTC">08:54PM - 17 Aug 20 UTC</span>
  </div>


  <div class="user">
    <a href="https://github.com/airtower-luna" target="_blank" rel="noopener">
      <img alt="airtower-luna" src="https://user-images.githubusercontent.com/5814919/181101633-f413e1be-335a-44cb-94…

View full answer

airtower-luna · 2021-06-14T11:39:50Z

airtower-luna
Jun 14, 2021

I’ve had that issue, too, unfortunately the bug report is still unresolved:

  <a href="https://github.com/actions/runner/issues/665" target="_blank" rel="noopener">github.com/actions/runner</a>

INPUT_* environment variables are missing in composite actions

<div class="github-info">
  <div class="date">
    opened <span class="discourse-local-date" data-format="ll" data-date="2020-08-17" data-time="20:54:00" data-timezone="UTC">08:54PM - 17 Aug 20 UTC</span>
  </div>


  <div class="user">
    <a href="https://github.com/airtower-luna" target="_blank" rel="noopener">
      <img alt="airtower-luna" src="https://user-images.githubusercontent.com/5814919/181101633-f413e1be-335a-44cb-9413-dd90e536743f.png" class="onebox-avatar-inline" width="20" height="20">
      airtower-luna
    </a>
  </div>
</div>

<div class="labels">
    <span style="display:inline-block;margin-top:2px;background-color: #B8B8B8;padding: 2px;border-radius: 4px;color: #fff;margin-left: 3px;">documentation</span>
</div>

[According to the documentation](https://docs.github.com/en/actions/creating-act…ions/metadata-syntax-for-github-actions#inputs) 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:

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

Use the action in a workflow:

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

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.

Use env as a workaround, e.g.:

    - run: ${{ github.action_path }}/entrypoint.sh
      shell: bash
      env:
        INPUT_TEST_INPUT: ${{ inputs.test_input }}

0 replies

38ri581oq480 · 2021-06-14T11:48:22Z

38ri581oq480
Jun 14, 2021
Author

thanks for workaround! 🤩
Is it safe to pass secrets in env from inputs?
For example:

- run: ${{ github.action_path }}/entrypoint.sh
  shell: bash
  env:
    SUPER_SECRET: ${{ inputs.super_secret }}

2 replies

lazarillo Nov 6, 2023

This seems problematic on two fronts:

You don't want to be passing secrets to inputs, but instead to secrets. Something like this.
As the link shows, you have now made $SUPER_SECRET available as an environment variable. So you'll have to make sure not to perform any output that shows its value.

The "trick" with using secrets in a bash environment is that you have to think of the cases where the secret might get leaked. For instance, if you did something like this:

python -m my_module param1 "$SUPER_SECRET"

Then if your program crashes or has an error, it is quite possible that the value in $SUPER_SECRET would be output as part of the stack trace (depending upon how it's being used in the module). Information can "leak" out when errors occur. And if the secret variable is no longer considered as secret (it's now just a normal environment variable), GH Actions cannot create any mechanisms to ensure that it isn't leaked out during output in a traceback or whatever.

airtower-luna Nov 6, 2023

You don't want to be passing secrets to inputs, but instead to secrets. Something like this.

Passing secrets to inputs is exactly what the example in the linked documentation does. An action (composite or otherwise) doesn't have direct access to secrets, it'll only receive those passed via inputs or environment.

And if the secret variable is no longer considered as secret (it's now just a normal environment variable), GH Actions cannot create any mechanisms to ensure that it isn't leaked out during output in a traceback or whatever.

Secrets get masked in workflow logs no matter how they secret got into there. There's no "it's no longer considered a secret" if you set an environment variable from a secret value.

What could be a problem is if the secret got obfuscated in some way (e.g. base64 encoded) and then logged, and slips through the masking process that way. Or if the secret got written to a file and that file uploaded as an artifact. Or if you call a malicious action that uploads a secret you gave it to somewhere. And so on. 😉

airtower-luna · 2021-06-14T11:56:45Z

airtower-luna
Jun 14, 2021

The SUPER_SECRET environment variable will be available to everything called from the command(s) defined in the run parameter. In this case that’s your script and anything it calls (unless the script overrides the environment variable). So it depends on your script. 🙂

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GitHub Community

Composite action inputs inside a shell script #27088

{{title}}

Replies: 3 comments 2 replies

{{title}}

INPUT_* environment variables are missing in composite actions

Runner Version and Platform

Job Log Output

Credit

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Composite action inputs inside a shell script #27088

Replies: 3 comments · 2 replies

Runner Version and Platform

Job Log Output

Credit

38ri581oq480 Jun 14, 2021 Author

Replies: 3 comments 2 replies

38ri581oq480
Jun 14, 2021
Author