ci: parse LuaLS json output instead of the pretty output

[Rathoz]

What

The luals-code-style step scraped LuaLS's human-readable output — stripping ANSI codes, then pulling counts out of prose. Now it uses --check_format=json and jq.

• Counts come from the JSON, so they're exact. The old grep -c 'Warning' reported 263 where LuaLS itself said 238 (one diagnostic can span several lines).
• Annotations and the pass/fail decision are now explicit. Previously the ::error lines were piped into grep, so they only reached the log because grep echoes what it matches, and the exit status came from inverting that grep.
• Summary gains a count of problems in changed files — the number that actually gates.

	Files scanned	Files with problems	Problems	In changed files
LuaLS check	1710	142	238	0

Gating behaviour is unchanged: annotate and fail only for files the PR touches.

How it was tested

luals-code-style skips unless lua/wikis/**/*.lua changes, so both paths were verified on a throwaway branch (since deleted):

• Clean changed file → In changed files: 0, job passes
• Changed file with a known problem → In changed files: 1, job fails, and GitHub registered the annotation at FilterButtons/Config.lua:27 — the exact line predicted locally

Also checked locally: JSON line/character are 0-based where annotations are 1-based (verified both 27:23 and 42:2 against the pretty output), a clean run writes [] rather than {} so the count needs // 0, and multi-line messages are flattened so they don't break the workflow command.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[mbergen]

I didn't know there is a JSON format available for output (it's not in the documentation on luals.github.io).
Using that and some jq parsing would probably improve the codestyle of this action drastically, so preferably we switch to that.

[Rathoz]

I didn't know there is a JSON format available for output (it's not in the documentation on luals.github.io). Using that and some jq parsing would probably improve the codestyle of this action drastically, so preferably we switch to that.

Done in 3f92ac7 — good call, it's a much better fit.

It also removes the reason this PR existed. The original fix was to stop grep -c 'Warning' overcounting (263 vs 238). Counting JSON array elements can't go wrong that way, so the bug is gone rather than corrected.

One thing worth knowing about the old pipeline while we're here:

sed -n 's/.../::error file=,line=/p' | (! grep -E "$changed_files")

The ::error lines were piped into grep, so they reached the log only because grep echoes the lines it matched, and the exit status came from inverting that grep. The behaviour was right, but by side effect. Both are now explicit, and the summary gained an In changed files column — the number that actually decides pass/fail.

Three details that needed checking rather than assuming:

• JSON line/character are 0-based; annotations are 1-based. Verified both ways against the pretty output (27:23, 42:2).
• A clean run writes [], not {}, so [.[] | length] | add yields null and the summary would have said "null problems". Needs // 0.
• Messages can contain newlines, which break the ::error command, so they're flattened.

Verified in CI on a throwaway branch, both paths: a clean changed file passes with In changed files: 0; a changed file with a known problem fails, and GitHub registered the annotation at FilterButtons/Config.lua:27.

Also — you're right that it isn't on luals.github.io. It's only in --help, alongside --check_out_path.