super-linter: C# validation extremely slow

Describe the bug We have a medium sized C# solution running with super linter. We are running super linter with RUN_LOCAL so every run ends up evaluating every file. We recently wanted to add C# linting since it was just added, but found that build times for linting all of a sudden spiked. The reason for this is the call to dotnet format takes roughly 2-3 seconds per file, whereas the tool seems to be meant to be run on csproj or sln files.

I compared a run of the the same linter running through super linter, and just the C# portion took roughly 7 minutes. I then used the troubleshooting instructions to get into the container and ran dotnet format --check against our solution file and it took 5 seconds to complete. An 8000+% increase in lint time is not acceptable for us in our build processes; when run times are in the order of minutes, the usefulness of the tool is lost and its faster to spin up a dotnet container, install dotnet format and run it.

To Reproduce As an example, lets run super-linter on the dotnet-format project 😃

Check out any C# project (as an example: https://github.com/dotnet/format)
Run docker run -e FILTER_REGEX_EXCLUDE=".*/(obj|bin)/.*" -e RUN_LOCAL=true -e VALIDATE_CSHARP=true -v `pwd`:/tmp/lint github/super-linter
Record the time it took to run. (dotnet-format took just under 4 minutes)
Run docker run -it -v `pwd`:/tmp/lint --entrypoint /bin/bash github/super-linter
Inside container, run dotnet format --check /tmp/lint/solutionfile.sln (replacing solutionfile.sln with the path to the solution)
Record time it took to run (Took 4700ms for me)

Expected behavior Super-linter run times should not be significantly different than running the tools against the support file types.

About this issue

Original URL
State: open
Created 4 years ago
Reactions: 1
Comments: 18 (7 by maintainers)

Most upvoted comments

#5177 should mitigate this, but we should probably handle .sln files as well

ferrarimarco on Jan 24, 2024

Yes, looking as sln files or csproj files would be the preferred method for this tool. Looks like dotnet format also supports a --folder flag that looks at all files within that folder, but that might not work as well because it won’t take into account the files that super-linter already ignores (such as node_modules).

Perhaps there could be a flag for specifying which extension you want to search for (sln, csproj, cs)? I think defaulting to csproj would be good because different sln files could overlap with the same csproj files (sln is just a collection of csproj)

omusavi on Sep 17, 2020

From my understanding of how super-linter works, when run as a github action it only runs on the files that have been modified, so if we were to set it to default to sln/csproj, it would not lint any changes to code files. However, when using RUN_LOCAL it ends up running against everything all the time, which is how we run it outside of the github context. So as not to break the experience on github actions, I think it makes sense to allow it as an option, or perhaps run it on **/*.csproj when RUN_LOCAL is set and **/*.cs when it is not?

omusavi on Oct 2, 2020