-
Notifications
You must be signed in to change notification settings - Fork 942
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C# validation extremely slow #736
Comments
@omusavi Thanks for the input. Would you think that if we looked for SLN files and then ran the linter against that, vs individual files, we could experience much better times? I'm not a C# dev, and we want to make sure this works well for everyone. I'm interested in some solutions we can take to speed this up and help everyone thanks |
Yes, looking as sln files or csproj files would be the preferred method for this tool. Looks like dotnet format also supports a 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) |
It seems like super-linter is built on sensible defaults, so what makes the most sense in most cases? Default to just scanning SLNs and let you configure another way if you'd like? Or default to **.cs as it does now and allow choosing a csproj or sln? |
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 |
This issue has been automatically marked as stale because it has not had recent activity. If you think this issue should stay open, please remove the |
Commenting as this is still an active issue |
This issue has been automatically marked as stale because it has not had recent activity. If you think this issue should stay open, please remove the |
Commenting as this is still an active issue |
This issue has been automatically marked as stale because it has not had recent activity. If you think this issue should stay open, please remove the |
Woot! Ready to see this fixed soon :) |
bump. Also is there a way to specify a solution instead of it going through each file one by one? |
I think if we were to replace this line with |
Any updates on this. This is causing my company to spend lots of money bc of the sheer amount of time it takes. It's getting to be ridiculous that it's not fixed yet. |
troubleshooting instructions |
@StephenHodgson Is this happening on the latest super-linter version? Can you try the steps in #736 (comment) with the latest available super-linter version, and see if the results are the same? We didn't change too much in this area, besides dependency updates, but let's start fresh anyway. |
No idea, that project has wrapped up and I no longer have access to it. |
Yeah, that makes sense to me @ferrarimarco! |
#5177 should mitigate this, but we should probably handle .sln files as well |
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 :)
docker run -e FILTER_REGEX_EXCLUDE=".*/(obj|bin)/.*" -e RUN_LOCAL=true -e VALIDATE_CSHARP=true -v `pwd`:/tmp/lint github/super-linter
docker run -it -v `pwd`:/tmp/lint --entrypoint /bin/bash github/super-linter
dotnet format --check /tmp/lint/solutionfile.sln
(replacingsolutionfile.sln
with the path to the solution)Expected behavior
Super-linter run times should not be significantly different than running the tools against the support file types.
The text was updated successfully, but these errors were encountered: