Run linter as Python package FileNotFoundError about cpp-linter-action HOT 4 CLOSED

Thanks for reporting this. I think I made a mistake in the revised logic that creates the executable cmd. Your workflow shows it trying to use the Linux cmd clang-tidy-12 when it should be resolving to just clang-tidy (or path\to\bin\clang-tidy.exe if specifying the binary exe's path as the version option).

I'll have a fix submitted by tomorrow, but I need to test it (more/better). I honestly don't know how our last test didn't show this problem.

BTW, the Windows runner comes with v13, not v12. Unless your boost lib cache includes/overwrites the clang version that comes with the Windows venv. Sometimes I get lucky with cross-version differences of clang-tools, but usually there's breaking differences in what clang-tools expects in their config.

from cpp-linter-action.

I honestly don't know how our last test didn't show this problem.

@2bndy5 Do you find the reason why our last test (in this run https://github.com/cpp-linter/test-cpp-linter-action/actions/runs/2527084295) did not show FileNotFoundError ? We'd better prevent it from happening again

from cpp-linter-action.

After researching the point of error, I found that red-panda-productions/DAISI workflow is improperly passing the version number to the version arg. When running on a Windows runner, the only ways to invoke a clang tool executable is to use

• clang-tidy / clang-format (this invokes whatever the default provided version is for the runner)
• path\to\bin\clang-tidy.exe / path\to\bin\clang-format.exe (this is used to specify a specifically installed version)

As stated in the README, Windows runners now come with v13 of the clang tools. If you want to use a specifically installed version on Windows then you have to pass the path it was installed to. (see example in README). Our python code will then check if the path has a bin folder and execute path\to\bin\clang-<tool>.exe (only the path\to part needs to be passed to the version arg).

To summarize, the working state of the red-panda-productions/DAISI workflow passes 12 to the version arg, but our action will only execute clang-<tool>. This ends up using v13 because (from what I can tell) v12 is not installed in the runner's environment, and calling clang-<tool> (without the .exe) invokes whatever executable is found in the OS's PATH env variable.

from cpp-linter-action.

My faulty logic revision in #66 (now fixed by #68) allowed this improper usage of the version arg to surface as an error. The bad logic ended up calling clang-tidy-12 on windows when that can only work on Linux (& possibly MacOS).

from cpp-linter-action.