Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core.getInput does not tell the caller if the returned value is defined in the yaml or not #272

Open
lukka opened this issue Dec 23, 2019 · 4 comments
Labels
core enhancement New feature or request papercut

Comments

@lukka
Copy link

lukka commented Dec 23, 2019

Describe the enhancement
core.getInput() should allow the caller to understand whether the value is explicitly set in the yaml file, or whether it is not.
Right now you get an empty string, either when it is not defined, either when the user defined it as an empty string.

Code Snippet

this would allow this code:

const inputValue = core.getInput(inputName) ?? defaultValue;

Right now you have to use this instead:

const inputValue = core.getInput(inputName) || defaultValue;

which is not the same.

Use case
e.g. An action's input is a string which is a list of flags, if the default is "-v" and the user wants to have no flags at all (e.g. flags: ""), having this explicitly stated as input (e.g. flags: "") would be always (uncorrectly) replaced by the default (when using ||). To overcome this the user is forced to define a in the yaml the input as blank space instead (e.g. flags: " ")

@lukka lukka added the enhancement New feature or request label Dec 23, 2019
@joshmgross
Copy link
Member

Action inputs support defining a default value in the action.yml file: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions#inputsinput_iddefault

core.getInput will handle using that value instead.

Is there a use case where defining the default in code after getInput is preferred?

@lukka
Copy link
Author

lukka commented Dec 23, 2019

Yes, if the default value is established at runtime (i.e. it cannot be specified in the action.yml).

@hross hross added the papercut label Mar 5, 2020
@TheMrMilchmann
Copy link

TheMrMilchmann commented Apr 3, 2020

To add to this, I'm currently running into an issue where an input parameter requires (basically) a relative path whose default is platform-dependent and thus, configured at runtime. In this case, since the empty string is a valid value, the behavior for explicit input (use the empty string) and no input (calculate platform-dependent default) should be different.

In the meantime, I ended up working around it by introducing another input parameter which serves as a boolean toggle for the abovementioned. (However, I don't think this is desirable.)

@mxcl
Copy link

mxcl commented Jul 4, 2021

I want to know if the user specified a YAML null, (ie. null or ~) where 'null' (the string) could be another possible input. I guess this is not possible.

@thboop thboop removed their assignment Oct 26, 2021
sandydoo added a commit to cachix/cachix-action that referenced this issue Oct 6, 2023
`getInput` returns empty strings instead of undefined/null.
See actions/toolkit#272
sandydoo added a commit to cachix/cachix-action that referenced this issue Oct 23, 2023
`getInput` returns empty strings instead of undefined/null.
See actions/toolkit#272
sandydoo added a commit to cachix/cachix-action that referenced this issue Jan 9, 2024
`getInput` returns empty strings instead of undefined/null.
See actions/toolkit#272
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core enhancement New feature or request papercut
Projects
None yet
Development

No branches or pull requests

6 participants