You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If possible, please provide a reproduction repository you discovered this bug in.
Unfortunately, the repository I detected this problem, is not a public one. Therefore, I cannot provide a link to it.
Which area/package is the issue in?
@koliveira15/nx-sonarqube
Description
Connected to my test coverage problem (see issue #112), I detected another issue in connection with vite 5.3.5 and nx v19.5.6 during my cause analysis. As mentioned already in the headline it is located in the src/executors/scan/utils/utils.ts file.
There is a getTestRunner method implemented (starting from line 55) that - in my case - was not able to detect the used test runner vitest at all. The reason was, that the function is checking three alternatives only:
if the test executor name contains vite,
if the test executor name contains jest or
if the test executor name contains run-commands.
None of these cases occurred in my project. I could find out that in my case the name was nx:run-script if I executed the command nx sonar <project_name>.
As a consequence, the test runner was not detected and stayed undefined which then prevented the following tasks using it from working.
Interestingly, the determinePaths function (same file, starting at line 89) later was able to know anyway that the test runner is vite. But this was by accident because in this function the test condition for this test runner is wrong (see line 167). It misses a comparison and is always true.
If applicable, please provide the Nx report
No response
Please provide the exception or error you saw
There was no error written out. The coverage report path was simply not found (always empty) and therefore the sonar scan did not perform a coverage analysis.
Other information
No response
I would be willing to submit a PR to fix this issue
Yes
No
The text was updated successfully, but these errors were encountered:
@ltparis2018 can you show me what your test executor looks like which is using the run-script? Using run-script implies you are using an npm script to test your project. If that is the case, the plugin will not be able to determine the test runner based on a script name since I can't account for all permutations.
If possible, please provide a reproduction repository you discovered this bug in.
Unfortunately, the repository I detected this problem, is not a public one. Therefore, I cannot provide a link to it.
Which area/package is the issue in?
@koliveira15/nx-sonarqube
Description
Connected to my test coverage problem (see issue #112), I detected another issue in connection with vite 5.3.5 and nx v19.5.6 during my cause analysis. As mentioned already in the headline it is located in the
src/executors/scan/utils/utils.ts
file.There is a
getTestRunner
method implemented (starting from line 55) that - in my case - was not able to detect the used test runnervitest
at all. The reason was, that the function is checking three alternatives only:vite
,jest
orrun-commands
.None of these cases occurred in my project. I could find out that in my case the name was
nx:run-script
if I executed the commandnx sonar <project_name>
.As a consequence, the test runner was not detected and stayed undefined which then prevented the following tasks using it from working.
Interestingly, the
determinePaths
function (same file, starting at line 89) later was able to know anyway that the test runner is vite. But this was by accident because in this function the test condition for this test runner is wrong (see line 167). It misses a comparison and is always true.If applicable, please provide the Nx report
No response
Please provide the exception or error you saw
There was no error written out. The coverage report path was simply not found (always empty) and therefore the sonar scan did not perform a coverage analysis.
Other information
No response
I would be willing to submit a PR to fix this issue
The text was updated successfully, but these errors were encountered: