-
Notifications
You must be signed in to change notification settings - Fork 979
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
Validate required inputs are set before invoking an action #1070
Comments
More info from my testing:
if I use |
We do provide the ability to set an input as required in core.getInput(), which will fail if an input is not set. The action.yaml is mainly for the benefit of the the runner/action author, we don't really use it in the toolkit. We do some validation on inputs in the runner already for unexpected inputs, we could also fail the step if the required inputs are not set. cc @TingluoHuang , @ericsciple , I'd love to hear your thoughts as well. |
I just ran into the same issue. Have to say it's quite unexpected to mark something as required and then finding out it blows up silently. Especially since toolkit is the official GitHub toolkit for actions.
I think this would make a lot of sense :-) |
This would improve the experience of developing actions, but would also break users that have erroneously set That being said, this isn't really a toolkit issue, the runner controls this. I'm going to transfer this issue to that repository. |
bump |
So what's the point of |
Bump, I was also surprised by this behavior (https://github.saobby.my.eu.orgmunity/t/inputs-required-not-enforced-with-no-default/206745/3). |
Does anyone have a one-liner workaround to enforce required parameters? |
Thanks @anukul , I was more wondering if there a way to write generic check, e.g. using JavaScript actions. However, it seems that it is impossible to get parent inputs. |
Something like this works: - run: |
[[ "${{ inputs.docker_image_name }}" ]] || { echo "docker_image_name input is empty" ; exit 1; }
[[ "${{ inputs.doppler_token }}" ]] || { echo "doppler_token input is empty" ; exit 1; } |
The Actions runner does not verify that inputs marked as 'required' are actually given: actions/runner#1070
Any updates with validating |
Also having the same issue. Would be nice to get this fixed. |
Would help as Im facing the same issue |
+1, had to turn debug logging on to realize this was my issue |
Hi, any update about it? |
Just ran into this as well. It'd be nice to get a clean failure of the using step when one or more required inputs are not provided. An error message should be printed and state which required input(s) were not provided. It'd be nice to have all the required but missing inputs printed in the message to avoid back and forth (hit the error, add one, hit the error again, ...). Thanks! |
Run into this as well, spent quite some time debugging an issue that would have been solved in 1' if github had let me know that a required input was missing 😬 |
Run into this as well |
It's been a couple of years, is it still the best good answer ? or did they fixed it ? |
Still not fixed. |
I ran into this issue too. I can imagine it cannot be just changed, as it would break too many things. But it could be an opt-in feature. |
I have the same question. |
Is this resolved now? I just got this:
|
Not fixed for actions.
This was never a problem for reusable workflows (your example), these are a newer concept. I agree GitHub Actions (CI/CD Product name) vs. actions (those are the steps of a job < this issue is about that part) vs. (reusable) Workflows (those are files having an |
🤔 Maybe something got changed but when I changed |
The issue people are describing doesn't affect the dispatch form that you're referring to in your comment. The people are complaining about the input required setting being ignored when calling a job from another job. The expectation was for the job to fail if not all required parameters are set, however it just continues like nothing. |
Does Maybe it's mentioned somewhere in the fine print above that this is indeed a no-op. Might be worth calling it out in the |
It doesn't do anything except to provide an intention to users. It's basically just documentation. Actions authors have to do all the input validation themselves currently. |
It seems like input types are also not enforced. I had assumed types |
Inputs are provided to actions as environment variables so they are only strings. The |
changing the update-dist workflow to use the `pr_number` input as an env variable to avoid [script injection](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#good-practices-for-mitigating-script-injection-attacks). Our workflows are only invokable by our trusted maintainers so we should be okay. This is just an extra hardening measure. Open issue actions/runner#1070 (comment) ## Testing I confirmed the issue by invoking the workflow with `650 && echo SCRIPT INJECTION`, and it did also do the extra `echo` command. - https://github.com/slsa-framework/slsa-verifier/actions/runs/9101350247/job/25018333703#step:3:36 after invoking the workflow again with this PR's version, the problem is mitigated. - https://github.com/slsa-framework/slsa-verifier/actions/runs/9101495332/job/25018812710#step:3:8 - https://github.com/slsa-framework/slsa-verifier/actions/runs/9101516757/job/25018888519#step:3:7 Signed-off-by: Ramon Petgrave <32398091+ramonpetgrave64@users.noreply.github.com>
changing the update-dist workflow to use the `pr_number` input as an env variable to avoid [script injection](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#good-practices-for-mitigating-script-injection-attacks). Our workflows are only invokable by our trusted maintainers so we should be okay. This is just an extra hardening measure. Open issue actions/runner#1070 (comment) ## Testing I confirmed the issue by invoking the workflow with `650 && echo SCRIPT INJECTION`, and it did also do the extra `echo` command. - https://github.com/slsa-framework/slsa-verifier/actions/runs/9101350247/job/25018333703#step:3:36 after invoking the workflow again with this PR's version, the problem is mitigated. - https://github.com/slsa-framework/slsa-verifier/actions/runs/9101495332/job/25018812710#step:3:8 - https://github.com/slsa-framework/slsa-verifier/actions/runs/9101516757/job/25018888519#step:3:7 Signed-off-by: Ramon Petgrave <32398091+ramonpetgrave64@users.noreply.github.com> Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
...b/c the GH runner doesn't: actions/runner#1070
...b/c the GH runner doesn't: actions/runner#1070
...b/c the GH runner doesn't: actions/runner#1070
Describe the bug
I have the following action.yml:
My index.js looks like:
and finally, the important part of my .github/workflows/test.yml:
Yet, there is no failure for missing anka-template... It fails for a reason inside of the ankaRegistryPull function which is well after it tries to load the input.
https://help.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#inputs seems to indicate that it shouldn't allow the action to run if it's missing that input.
What am I missing?
The text was updated successfully, but these errors were encountered: