Differentiate between input parameter empty or not present

[rsenden]

Current behavior:

• If an input parameter is defined in action.yml (without default value), GitHub will set the INPUT_PARAMNAME environment variable to an empty value if the parameter is not present in the workflow

Expected behavior:

• If an input parameter is defined in action.yml (without default value), GitHub should not set the INPUT_PARAMNAME environment variable to an empty value if the parameter is not present in the workflow

Possibly related issue for JavaScript actions: actions/toolkit#272

Resources that illustrate this issue:

• Dockerfile: https://github.com/rsenden/test-empty-var-action/blob/master/Dockerfile
• GitHub Action for this Docker image: https://github.com/rsenden/test-empty-var-action/blob/master/action.yml
• Sample workflow that invokes this Docker image both directly and through the action, with the test input parameter not set: https://github.com/rsenden/test-empty-var-action/blob/master/.github/workflows/notset.yml
• Workflow output: https://github.com/rsenden/test-empty-var-action/runs/1707506513?check_suite_focus=true

As can be seen in the workflow output, results are different between running the Docker image directly or through the GitHub Action.

This can cause issues if a Docker image (or other action implementation) differentiates between 'empty' and 'not set'. If an action wants to set an empty value as the default value, then this should be done using the default property in the action definition.

Can you please get this fixed?

[hross]

This is currently a low priority for us in terms of where it falls in our bug priority. I am marking it a papercut but I don't expect us to be able to get to fixing it soon.

[lucacome]

I just stumbled on this, any way those PRs are going to be merged anytime soon?

[shrink]

@hross if anything is needed from my end to move the merge of my fixes forward, please let me know, happy to do any additional work required to get this fixed :-)

[rethab]

Hi @hross I'd like to bring this to your attention again. This problem is made worse in combination with reusable workflows:

Specifically, while the author of an action cannot distinguish between "no input passed" and "empty string passed", the runner does seem to distinguish between the two when deciding whether to use defaults: If an empty string is passed as an input, then the default value is not used, but when the input is omitted entirely, then the default is used.

Now consider reusable workflows. Imagine a main workflow that calls a reusable workflow which in turn calls an action. There is one input, which is passed all the way down to the action. If the main workflow doesn't specify the input to the reusable workflow, then the runner still turns that into an empty string. That empty string is then passed on to the action, where the default value is not used.

So it is the runner that turns "no input passed" into "empty string passed" and then it reaches the action where the default is not used. This makes it tricky to handle default values with reusable workflows.

Also cc @chrispat

Example

Action

name: Test
description: Test Action

inputs:
  greeting:
    required: false
    description: 'Greeting to use.'
    default: 'Hello'

runs:
  using: 'composite'
  steps:
    - run: echo ${{ inputs.greeting }} Earthling
      shell: bash

Partial Workflow

on:
  workflow_call:
    inputs:
      greeting:
        description: "The greeting to use"
        required: false
        type: string

jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: ./
        with:
          greeting: ${{ inputs.greeting }}

Main Workflow

jobs:
  greet:
    uses: rethab/actions-test-repo/.github/workflows/partial.yml@main

Output

[sean-m-sullivan]

Hello @hross I've been looking into an issue with a Github marketplace action, and found that this also is an issue there. It is nearly if not completely impossible to evaluate an input argument as null without these changes going through. I highly support this PR to go through.

[SushmitaGoswami]

Do we have a solution for this?

[abower-digimarc]

Hello, this is an issue for me as well.

I have an action, I want to specify a default value.

However, as described by @rethab here, when I use an action with reusable workflows, 'no input' is changed to 'empty string' above the action, thus the action never uses the default value.

Not only is this not well documented, resulting in unexpected behavior (i.e., the default value never gets consumed by my action), it does seem a bug.

[druskus20]

This is also a problem for me, which renders default values almost useless in reusable workflows or composite actions.
The fact that there's no distinction between these two means that we need to propagate default values for input parameters throughout the chain of actions.

[dbsanfte]

This is a very nasty gotcha for anyone trying to build reusable workflows across a Github organisation. We are an enterprise customer and would greatly appreciate you fixing this.

[kkurczewski]

I don't know why this is marked papercut, it is second most voted issue and it isn't a debatable feature but a freaking bug. And reported back in 2021!

After a honeymoon with Github Actions I start to think that I can't wholeheartedly recommend it in my next projects because it is basically dead project and is deaf to its clients. Better to put money somewhere else or roll something open source.

[shrink]

@TingluoHuang I think this issue has slipped through the cracks as @hross doesn't appear to work at GitHub any more. I'm not sure who is responsible for the runner, but as you're the most active contributor to actions/runner, are you able to take a look at this and determine whether it can be addressed? There's an open Pull Request I created a few years ago with a proposed fix (#1176) and a companion Pull Request for actions/toolkit (actions/toolkit#849). If this isn't a bug, or it's bug that isn't going to be fixed, could you close this issue as won't fix (or equivalent)? Thank you.

[flowchartsman]

Here's a more concrete example of where this feature would save people a lot of frustration and pain:

I was attempting to use google-github-actions/auth to set up google cloud credentials to upload release artifacts. The documentation states that you can provide one of workload_identity_provider or credentials_json in the parameters, which I was attempting to do via a secret:

    - uses: 'google-github-actions/auth@v2'
      with:
        credentials_json: '${{ secrets.EXAMPLE_CREDENTIALS }}'

This did not work, and the root cause ended up being that I had defined this particular secret in an environment, but had neglected to set the environment on the job; however, because there is no meaningful way to detect the difference between an empty parameter and none at all, it was treated as if I hadn't provided the parameter, leading to a very misleading error of:

 the GitHub Action workflow must specify exactly one of "workload_identity_provider" or "credentials_json"! If you are specifying input values via GitHub secrets, ensure the secret is being injected into the environment. By default, secrets are not passed to workflows triggered from forks, including Dependabot.

Which is about as helpful as a kick in the teeth when someone is looking at a YAML workflow definition that appears to explicitly declare a parameter and a secret value to put in it. In this case it's made even worse thanks to the ambiguous meaning of "environment" and the admonition to "ensure the secret is being injected into the environment" -- do they mean github environments or environment variables? The term "inject" is also ambiguous and seems to imply using an environment variable, which is actually incorrect here.

I know it is not github's responsibility to police error messages in 3rd-party actions; however, if this feature were available actions could at least have the ability to provide more meaningful errors.

Having to hunt this down was a deeply unpleasant exercise and wasted a lot of time, whereas a more meaningful error message such as:

credentials_json provided, but the value was empty; your secret may be undefined or exist within an environment, in which case you need to attach the environment to the workflow

from the action or:

found a secret "credentials_json" that is empty; is it in a different environment (etc, etc)

from the actions runner would have saved me time and stress.

There is, of course, no guarantee that an action would take advantage of this feature, but it absolutely should have the ability to do so, if it wants.