Fix GitHub Actions Composite Action Input Errors
Resumen
Pixel shares a guide to two common GitHub Actions composite action issues: undeclared inputs that trigger warnings and missing shell properties that prevent actions from loading. It explains how to distinguish the errors and fix the action.yml metadata, helping the community troubleshoot workflows faster.
DEV Community
GitHub Actions composite action unexpected input
GitHub Actions composite action unexpected input is the runner warning Unexpected input(s) 'x', valid inputs are [...]: a key in your with: is not declared under inputs in the action's action.yml, so the value is dropped and the step carries on without it. Its fatal neighbor, Required property is missing: shell, means a run step inside the composite action has no shell, and the fix is to add one, such as shell: bash, to every run step. Two separate checks on two separate files. The metadata is validated first and fails the job; the input names are compared second and only warn. What this error means Two different failures wear this label and they are worth separating on sight. The first is a warning: the step runs, the job is green, and one option you thought you set had no effect, with a line in the log naming the key you passed and listing the ones the action accepts. The second is fatal and arrives before anything runs: the action fails to load, and the message names a file, a line and a column inside the action rather than inside your workflow. Both are decided by reading the action metadata. ```Actions log, quoted from grafana/install-alloy#2 Error: grafana/install-alloy/main/action.yml (Line: 13, Col: 7): Required property is missing: shell Error: GitHub.DistributedTask.ObjectTemplating.TemplateValidationException: The template is not valid. grafana/install-alloy/main/action.yml (Line: 13, Col: 7): Required property is missing: shell [three stack frames omitted] Error: Failed to load grafana/install-alloy/main/action.yml
Common causes
The input is not declared in the action metadata
The ordinary case, and usually a spelling or a separator: an underscore where the action uses a hyphen, a plural where the action is singular. The identifier rules allow both spellings, so nothing about the name is invalid, it is just not the one the action published.
A composite run step has no shell
The step key that is optional everywhere else and required here. It is easy to lose when a run step is copied out of a workflow into an action, because in a workflow the job default supplies it. The action then fails to load for every caller at once, which is why this often arrives as a report from a consumer.
The action is read from a different ref than you think
The valid list is built from the metadata at the ref you pinned. A floating major tag that moved, or a local action on a branch you did not check out, gives a list that does not match the documentation you were reading. Pinning to a SHA removes the question.
The value is read through the toolkit rather than the context
Inside a composite action the input environment variables are not set, so a nested script action asking the toolkit for an input gets an empty string. Nothing warns, because from the runner's point of view the input was accepted and passed on as declared.
How to fix it
Read the file position in the message first
- If the path in the error is an
action.yml, the metadata is the problem and the job will not start. - If the message is a warning naming a key and a valid list, the metadata loaded and only the name is wrong.
- If neither appears and the value is empty inside the action, it is declared but read the wrong way.
Put a shell on every composite run step
There is no job default inside an action, so each run step carries its own. Anything on the documented shell list works; bash is the portable default on the hosted Linux and macOS images and is available on the Windows ones.
.github/actions/setup/action.yml (illustrative)
runs:
using: composite
steps:
- run: ./install.sh
shell: bash
Declare the input, then read it through the inputs context Declaring it makes the key expected; reading it through the context is what makes the value arrive. Give optional inputs a default so the action behaves predictably when the caller says nothing, and remember that every default is a string..github/acti...

Powered by Readybot.io