fix-linter-test

Debug the failing test for $ARGUMENTS.

Steps:

1. Find the test file in megalinter/tests/test_megalinter/linters/
2. Check if it's auto-generated (has @generated by .automation/build.py header) — if so, fix the descriptor YAML or fixtures, NOT the test file itself
3. Read the descriptor YAML in megalinter/descriptors/ to understand expected behavior (clilintmode, supportedclilintmodes, configfilename, clilinterrorsregex, file_extensions)
4. Check test fixtures in .automation/test/<test_folder>/:

- Good files must pass the linter cleanly - Bad files must trigger errors matching clilinterrorsregex - File extensions must match fileextensions or filenamesregex in the descriptor

1. If a custom linter class exists in megalinter/linters/, review it for issues
2. Common failure causes:

- Fixture file extensions don't match descriptor's fileextensions - clilinterrorsregex doesn't match actual linter output format - Missing config file referenced in configfilename - clilintmode mismatch (file vs listoffiles vs project) - supportedclilintmodes lists a mode the tool can't run — the per-mode tests (testsuccess<mode>lintmode / testfailure<mode>lintmode) run for every declared mode; if a failure is confined to one mode, remove it from supportedclilintmodes (unsupported modes are auto-skipped) - Version pin broken or tool not installable in Dockerfile - Linter behavior differs between host OS and Docker container (Linux) - testsuccessprojectlintmode fails on a file under .wireit/: that is a poison fixture guarding excluded-directories forwarding (see .claude/rules/testing.md). The forwarding is broken, not the fixture — check the command in the log for the forwarded exclusion arguments and the [Excluded directories] trace line, then review the descriptor's clilintmodeprojectexclude* properties or the class manageexcludeddirectoriesconfig() / buildlintcommand override (a custom buildlintcommand that does not call super() bypasses forwarding). Do NOT delete the poison fixture to make the test pass

1. Reproduce in Docker (required — linters are not installed locally):

``bash LINTER="<descriptoridlowercase><lintername>" docker buildx build --platform linux/amd64 --file linters/$LINTER/Dockerfile --tag $LINTER . docker run --rm --env TESTCASERUN=true --env OUTPUTDETAIL=detailed \ --env TESTKEYWORDS="${LINTER}test" --env MEGALINTERVOLUMEROOT="." \ --volume "$(pwd):/tmp/lint" $LINTER ` To run only specific test methods, use a -k-style substring (matches all modes): `bash # all failure-mode tests (testfailurefilelintmode, listoffiles, project) --env TESTKEYWORDS="${LINTER}test and testfailure" # narrow to a single mode --env TESTKEYWORDS="${LINTER}test and testfailureprojectlintmode" ``

1. In CI, filter tests via commit message body: TESTKEYWORDS=<linter>test
2. Update CHANGELOG.md only if the fix changes user-visible linter behavior (wrong error count, missed files, broken output). Add one line under Fixes in the beta section:

``text - Fix <linter-name>: <what was wrong and what users now get> ` Do NOT add an entry for test-infrastructure-only fixes (fixture paths, test class regeneration, etc.). Style: .claude/rules/changelog.md` (written for end users, no internal details).