actions/runner

Unwanted warning for undefined input variable in action.yml

Yanjingzhu opened this issue · 7 comments

Yanjingzhu commented

Customer developed an action with dynamic inputs, when specify inputs which not mentioned in action.yml, warning will show on logs:

##[warning]Unexpected input 'service', valid inputs are ['file']

Is there a way to avoid this warning? The issue is also happened in octokit/request-action .

There is the ticket in community forum.

Yanjingzhu commented

#506 This PR is related.

nick-invision commented

My PR #506 will at least reduce the number of warnings from 1 per input, per action to 1 per action. My workflow summaries are now just noise and worthless because I have dozens of the same Unexpected input... warnings for dynamic inputs that are expected.

TingluoHuang commented

@nick-invision thanks for your feedback and contribution, I have merged your PR and will include in the next runner release.

We add the warning to help the customer better debug their workflow runs like you have a typo when providing inputs in the workflow YAML file.

  • 👍2
gr2m commented

@TingluoHuang I have two actions in particular that depend on undefined inputs:

  1. https://github.com/octokit/request-action/
  2. https://github.com/octokit/graphql-action/

There is no way I can define all possible inputs. Several users complained about the warnings.

Could you please add an option that allows me to explicitly allow undefined inputs?

  • 👍4
AlexShemeshWix commented

It confuses my developers

allenevans commented

It would be great if there was a way to suppress this warning. This was the original behaviour when I created my action, but changed after #429 was merged.

I now have an open issue allenevans/set-env#7 that I cannot resolve since the input parameters cannot be known ahead of time in action.yml

  • 👍2
charles-allen commented

We add the warning to help the customer better debug their workflow runs like you have a typo

This is a great idea in principle, but I only need to fix a typo once.
A permanent YELLOW build is a terrible trade-off for a minor one-time issue.

Accurate real-time status is literally the only job of CI -- what's the point of CI if it always shows "broken"?
Please add warning suppression to GitHub Actions

Ideas:

  • Add a job property that takes a boolean: suppress-warnings: true
  • Add a job property that takes a regex pattern suppress-warnings: 'Unexpected input(s)*'
  • 👍11