You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Runner 2.333.0 rejects vars context in composite actions that 2.332.0 accepted #4311
After the GitHub Actions runner was updated from 2.332.0 to 2.333.0, composite actions that reference the vars context (e.g. ${{ vars.AWS_REGION }}) now fail at parse time with:
Unrecognized named-value: 'vars'. Located at position 18 within expression: inputs.region || vars.AWS_REGION || 'ap-southeast-2'
This is a regression. The same composite action with the same vars references worked on runner 2.332.0 and fails on 2.333.0.
The composite action should resolve vars.AWS_REGION at runtime (as it did on 2.332.0), or at minimum silently fall through to the hardcoded default when the context is unavailable.
Actual behaviour
The runner rejects the template at parse time before any step executes:
##[error] Unrecognized named-value: 'vars'. Located at position 18 within expression: inputs.region || vars.AWS_REGION || 'ap-southeast-2'
Evidence
Two CI runs on the same repository, same workflow, same composite action. The composite action was not modified between runs. The only difference is the runner version:
Runner 2.332.0: Deploy job succeeds
Runner 2.333.0: Deploy job fails with the error above
Apologies, vars was never intentionally supported.
#4147 which shipped with v2.331.0 accidentally removed validation that would have produced an error for vars, when the associated feature flag sent down from the server was true.
Note, we also filter vars sent down to the runner, based on what's referenced directly in the job's YAML definition.
So any vars reference from the composite action would have resolved empty, unless the same var was also referenced directly from the job's YAML definition.
Thanks for the quick and thorough explanation, @ericsciple. The timeline and details about the server-side filtering are especially helpful — good to know the vars references in our composite actions were resolving empty all along.
We'll update our composite actions to remove the vars fallback and rely on input defaults instead. Straightforward fix on our end.
Activity
ericsciple commentedon Mar 25, 2026
Apologies,
varswas never intentionally supported.#4147 which shipped with v2.331.0 accidentally removed validation that would have produced an error for
vars, when the associated feature flag sent down from the server was true.#4279 which shipped with v2.333.0 fixed ☝️
fix: add `vars` context to composite action schema
ericsciple commentedon Mar 25, 2026
It looks like the associated server feature flag was enabled on 2026-01-22
So
varswould have accidentally not produced an error between 2026-01-22 and the v2.333.0 releaseericsciple commentedon Mar 25, 2026
Note, we also filter
varssent down to the runner, based on what's referenced directly in the job's YAML definition.So any
varsreference from the composite action would have resolved empty, unless the same var was also referenced directly from the job's YAML definition.v2.333.0 correctly produces an error now.
charlesjiang-greengate commentedon Mar 25, 2026
Thanks for the quick and thorough explanation, @ericsciple. The timeline and details about the server-side filtering are especially helpful — good to know the
varsreferences in our composite actions were resolving empty all along.We'll update our composite actions to remove the
varsfallback and rely on input defaults instead. Straightforward fix on our end.Appreciate the fast turnaround on this.
suwarli476-cyber commentedon Oct 9, 2026
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: my-org/my-action/.github/actions/my-composite@main
with:
region: ap-southeast-2