Repository navigation
Documentation bug: expression numbers are mis-documented #43008
Description
Code of Conduct
- I have read and agree to the GitHub Docs project's Code of Conduct
What article on docs.github.com is affected?
The "Literals" section of the GitHub Actions expression syntax page:
https://docs.github.com/en/actions/reference/workflows-and-actions/expressions#literals
That link is for the "Free, Pro, and Teams" page, but the GHES and GHEC pages are also affected.
What part(s) of the article would you like to see updated?
The number literal is documented as "Any number format supported by JSON." However, in reality, the GitHub Actions expression parser takes a much larger set of literals, which it coerces to numbers.
For example, neither hex nor octal literals are valid in JSON, but GitHub Actions accepts them. For example:
${{ 0xff }}
${{ 0o777 }}
More generally, GitHub Actions appears to support any number literal that the JavaScript Number(...) constructor can coerce a string from. Those coercion rules are documented here:
This can be seen in the official GitHub Actions expression parser, which appears to use the Number(...) constructor when turning a StringData lexeme into a number:
Additional information
Yes, this is trivially reproducible in any GitHub Actions workflow or action definition.
See zizmorcore/zizmor#1628 for a related downstream report.
Activity
woodruffw commentedon Feb 19, 2026
@DarkaMaul has also observed that numbers in expressions don't fully adhere to the
Number(...)coercion rules:zizmorcore/zizmor#1628 (comment)
This means that it's pretty unclear where the semantics for numbers are actually coming from in GitHub Actions expressions. It'd be really great for the docs to offer more clarity here.
yolandahenderson670-code commentedon Feb 19, 2026
Sharra-writes commentedon Feb 24, 2026
@woodruffw This looks fairly fundamental and important, so I will try to get an answer about it in a timely manner, but just be aware that the Actions team is dealing with a lot and aren't quick to get back to me about anything at the moment. Just for my own clarification, is the documentation accurate in saying "any number format supported by JSON" in the sense that it does support all number formats supported by JSON, it just also supports other number formats? Or is that claim inaccurate? Sometimes things work that aren't officially supported, and that's always a whole headache with the documentation.
woodruffw commentedon Feb 24, 2026
Hi @Sharra-writes, thanks for the response!
It's accurate in the sense that it supports a superset of the number formats supported by JSON. In other words, all JSON numbers are parsed correctly, but a lot of other number formats (broadly, a subset of the ones accepted by JavaScript's
Number(...)) are also supported.@DarkaMaul triaged this and found the relevant code here, which does a lot more than JSON numbers:
https://github.com/actions/runner/blob/052dfbdd6864f9335a53e1b685aaa8e3f1f26d04/src/Sdk/Expressions/Sdk/ExpressionUtility.cs#L223
github-actions commentedon Apr 27, 2026
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
woodruffw commentedon Apr 27, 2026
This is definitely not stale.
65jun3456cub-pixel commentedon Apr 27, 2026
github-actions commentedon Aug 31, 2026
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
woodruffw commentedon Aug 31, 2026
This is definitely not stale.
woodruffw commentedon Aug 31, 2026
@Sharra-writes is there any chance of getting these docs fixed? I think this is unfortunately still pretty misleading as-is.
subatoi commentedon Sep 1, 2026
@woodruffw I've removed the
stalelabel and ensured it shouldn't be re-added. We'll do our best to get this in front of the right people as soon as possible, but unfortunately we can't guarantee a timeframe for responses and resolutions for issues generated via this repo. Thanks for your patience.