The GitHub Actions unexpected input valid inputs are warning
A GitHub Actions unexpected input valid inputs are warning never fails the step, which is why the run goes green with the option you set doing nothing at all. The runner compares the keys under with: against the inputs the action declares, and lists every valid one for you in the same line.
What this error means
The step succeeds. The run is green. The thing you configured did not happen: the cache was not used, the version was not pinned, the token was not passed. Somewhere in the collapsed group at the top of the step there is a warning naming your key and listing the keys the action does accept, and because it is a warning it does not surface as an annotation on the job the way a failure would. Two situations look identical from the outside. Either the key is misspelled, in which case the list in the warning contains the one you meant, or the key was real in a different version of the action, in which case the list is the new set and the input you are passing has been renamed or removed since the version you copied the snippet from.
##[warning]Unexpected input 'service', valid inputs are ['file']A minimal workflow that produces it
This file is written for this page and has never been run. One key is right and one is a plausible guess, and the difference between them is an underscore. The step installs a runtime and succeeds, so the only evidence that the second key did nothing is the warning inside the step group.
name: ci
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: actions/setup-node@v7
with:
node-version: 22
cache_dependency_path: package-lock.json
- run: npm ci --no-audit --no-fundCommon causes
The key is misspelled
An underscore where the action uses a hyphen, a plural where the action uses a singular, or a name borrowed from a different action that does something similar. The list in the warning contains the right spelling, which makes this the fastest of the four to fix once anybody reads it.
The input belongs to a different version of the action
A snippet copied from a blog post or from an older workflow, pinned against a newer major version. Inputs get renamed and removed across majors, and nothing in the workflow file records which version the snippet was written for. In our experience this is the version that appears in batches, right after a dependency bot raises every action at once.
The action takes dynamic keys it cannot declare
Some actions forward arbitrary keys to an API or a CLI, so the metadata lists a small set and users pass more. The warning is then correct and harmless, and it is also permanent, which is the complaint in actions/runner#514 and the reason the check cannot be made stricter.
The key belongs to the step rather than the action
Workflow-level keys such as env, if, continue-on-error and timeout-minutes are siblings of with:, not entries inside it. Indenting one of them under with: turns a step setting into an action input the action has never heard of, and the setting silently stops applying.
How to fix it
Read the list in the brackets and copy from it
- Expand the step group in the log and find the warning.
- Look for the input you meant in the list after "valid inputs are".
- If it is there, fix the spelling; if it is not, the pinned version does not have it.
Check the metadata of the exact ref you pinned
The list in the log is generated from the action.yml of the version you referenced, so the authoritative source is that file at that tag rather than the README on the default branch. Reading the tag you actually use settles the rename question in one look.
gh api repos/actions/setup-node/contents/action.yml?ref=v5 \
--jq '.content' | base64 -d | head -40Move step keys back out of the with block
Anything that configures the step rather than the action sits at the same indentation as uses:. If the warning names something like env or timeout-minutes, the fix is indentation rather than spelling.
- uses: actions/setup-node@v7
timeout-minutes: 5
env:
NODE_ENV: test
with:
node-version: 22Make the warnings visible instead of collapsed
Since nothing fails, the only reliable catch is a search. Grep the workflow run logs for the warning text after a batch of action bumps, or add a lint step that validates with: keys against the pinned action metadata, which turns a silent misconfiguration into a red check.
What the runner is actually comparing
The check is a set difference, and it lives in ActionRunner.cs in actions/runner. The runner collects the keys you wrote under with:, collects the input names the action declares in its metadata, and warns about every key in the first set that is not in the second. The message is built as Unexpected input(s) '{joined unexpected}', then valid inputs are ['{joined valid}'], which is why the list in the brackets is complete rather than a suggestion. The 2020 log quoted at the top predates that wording: the runner writes Unexpected input(s) today, and names every unrecognized key rather than one.
So the second half of the warning is the action documentation, printed into your log by the tool that read it. If the input you wanted is in that list under a different spelling, it is a typo. If it is not in the list at all, the version you pinned does not have it.
Where the valid list comes from
An action declares its inputs in its metadata file, and the reference is specific about the identifier: "A string identifier to associate with the input. The value of <input_id> is a map of the input's metadata. The <input_id> must be a unique identifier within the inputs object. The <input_id> must start with a letter or _ and contain only alphanumeric characters, -, or _."
That last clause is why the mistake is so easy. Hyphens and underscores are both legal, so both spellings look right and neither is obviously wrong to a reviewer. The authoritative answer is the action.yml of the exact ref you pinned, and the warning in the log is a copy of it.
- uses: actions/setup-node@v7
with:
node-version: 22
cache: npm
cache-dependency-path: package-lock.jsonWhy it is only a warning
Because some actions take keys their metadata cannot describe. actions/runner#514 is the request that documents the tension: an action built for dynamic inputs, a user passing keys the metadata does not list, and a warning on every run that nobody can remove. The runner has no way to tell that case apart from a typo, so it reports both and fails neither.
The practical consequence is that this never breaks a build and never will, so nothing but a reviewer or a log search will catch it. Treat it as an error in review even though the runner does not, because the whole cost of this one is the option you thought you had set.
Why there is no recorded run on this page
The warning comes from the runner reading two lists and comparing them, and it is deterministic: the same workflow produces the same warning on every run, on any runner. There is nothing transient to retry and nothing for a runner to repair, so this page carries no reproduction and makes no claim about one. The warning quoted above is from a public issue and the workflows are illustrative.
How to prevent it
- Copy input names from the
action.ymlof the ref you pin, not from a README on the default branch. - Re-read the inputs whenever a dependency bot raises an action across a major version.
- Treat an unexpected-input warning as a review blocker, because the runner will never block it for you.
- Keep step keys such as
envandifat the same indentation asuses:, outside thewith:map.
Frequently asked questions
What does "Unexpected input(s), valid inputs are" mean?
with: against the inputs the action declares and found one it does not recognize. It lists every valid input in the same line, so the answer is usually visible in the message. The action never received your key, which is why the option you set had no effect.Does an unexpected input fail the workflow?
Why did this warning appear after I bumped an action version?
action.yml at that tag rather than the README on the default branch, since the default branch may be ahead of the ref you pinned.