Closed olbrich closed 7 years ago
I get the same
@olbrich @jaredhales I've suffered this exact same issue, but the problem is not only one, but two:
timeout: 30000
(in milliseconds), and it should be fixed.I've checked that explicitly providing the timeout
value fixes the second issue, which is the main topic of the current GitHub issue.
EDIT: I think the most clear way to fix this would be adding an option to the settings page for timeout with a default value of 0
, which waits until the codeclimate command exits naturally (with or without error).
@olbrich @jaredhales I've made a PR to fix this issue among others.
You can use it until merged by providing my fork like this: apm install cgalvarez/linter-codeclimate
.
You can share your feedback if find any more issues.
You can add another key-pair like timeout: 30000 (in milliseconds), and it should be fixed.
@cgalvarez it seems to better for me by specifying timeout as you've outlined
Also, it's worth noting that my Codeclimate executable was actually taking very long sometimes (possibly not even working?). I upgraded the CLI and it pulled down a new CLI and then I updated a bunch of the engines as well. Might be worth putting a reminder about keeping the CLI up-to-date in the Codeclimate linter settings pane of Atom.
I don't know about anyone else, but I'm still seeing this. A lot. The codeclimate linter has in fact been useless for me for quite some time.
Hi @mshappe. This issue should be fixed with the latest merged PRs. Please, provide some info about your environment set up and the version of linter-codeclimate
and codeclimate
you're using.
I need a reproducible example because I don't suffer this issue anymore in my projects.
I think i've successfully worked around it by turning off the timeout in the settings, but since I doubt that codeclimate was actually taking 10 seconds to do its work on relatively small files, it's not clear to me why it was ever timing out.
It can take even much more time. Take into account that codeclimate
is not a standalone binary. It is a shell wrapper to execute the real command inside a Docker container, so Docker needs to start the related container, and then execute the command. Although you were using only a small file, the analysis on that file should start at least another container per engine to perform the analysis, and execute the related analysis command on each engine container.
This is not the fastest op. You can open atom in debug mode and you will see the real time the codeclimate analysis took in the console. Then you can check how the same analysis performs from the command line, and check whether it takes much more time or not.
Usually one thinks that the analysis really takes much less time because the output of the analysis is sent in real time in the terminal, but linter-codeclimate
must wait for the whole analysis to finish before it can parse all the results (which may take a bit) and send to atom-linter
.
Net result is a popup warning on larger files/projects that indicates a problem, but then resolves.
I see 'Error running Code Climate Error: Process execution timed out' in the developer mode console as well. Is there a way to configure the timeout or just make it longer?