Detekt generated report doesn't include everything - kotlin

I recently started using detekt in order to fix common issues within a project. I used the generated .html file to locate and fix the issues manually.
I noticed that not every Detekt issues is reported within the reports even though the Detekt marked it as an issue.
So there are MaxLineLength issues which the detekt marked and i can see them inside Android Studio but i can't find them inside any of the reports

Related

HelloWorld in Kotlin gives error "Could not find or load main class"

I spent the last 1,5 hour trying to make this simple tutorial work in IntelliJ IDEA, as you can see in this video.
When trying to run the code, I get the error:
/[...] -Dfile.encoding=UTF-8 src.HelloKt
Error: Could not find or load main class src.HelloKt
Caused by: java.lang.ClassNotFoundException: src.HelloKt
I have tried setting up SDK, invalidating cache, removing .idea and .gradle, rebuilding project, deleting the profile and adding it again. I tried those actions in different orders.
Here's a screenshot of the project:
It also complains Kotlin is not configured, but I have already configured it.
Here's the run configuration:
Here are the project settings:
Your Hello.kt file needs to be somewhere inside the src/main folder, probably in src/main/kotlin. This is different from the tutorial, because your project is using Gradle, and the one in the tutorial isn't. I think this is because newer versions of IntelliJ use Gradle by default for new projects, which wasn't the case when the tutorial was written.
The use of src/main/kotlin and src/test/kotlin as source code directories is a convention in Gradle (and Maven). When importing a Gradle project into IntelliJ, main becomes a module, and kotlin becomes a source folder within that module. The same goes for test. In your screenshots, the bold text and blue icons on main and test confirm that's how your project is set up. Files outside of those folders aren't treated as source files, which explains why your Hello.kt file isn't being compiled or recognised correctly.
It's likely that the default behaviour of IntelliJ when creating a new project has changed since this tutorial was written. In the tutorial, they select "Kotlin" as the project type and this creates a project that doesn't use Gradle. As a result, the project doesn't use the src/main/kotlin directory structure.
I can see from your video that you selected the same option, but on the next screen, IntelliJ still automatically selected Gradle as the build system for the new project. To match the project structure used in the tutorial, I think you would need to select "IntelliJ" as the build system.

connectedAndroidtest mergeAndroidReports not working

I'm trying to run two different sets of instrumentation tests in two different modules. It's my understanding that if I add the mergeAndroidReports command to each of these test tasks that in the root project in the build folder I should see a test report which combines all tests run.
At this moment I see a test report in each module created as well as a blank test report created at the project level build folder.
It appears it's setting up the blank report to combine but not actually completing the report. Has anyone run into issues using the mergeAndroidReports command?
Extra info:
I have the following added to the project level build.gradle file:
apply plugin: 'android-reporting'
Again there are no errors and I do see the following directories are being generated at the project level:
build/reports/androidTests/index.html
But this is empty: nothing is added to this report.
Has anyone experienced this issue?

TFS Build ignores configured Code Analysis ruleset

I have a solution that is using an hybrid .csproj and project.json combination (for nuget management purposes). So basically the "project.json" file is working as a "packages.config" file with a floating version capability.
This solution is using a custom RuleSet that is being distributed via Package, and is imported automatically. On the dev machine, works without a problem.
At the build machine (that is, inside the machine itself, working as an user) the solution also compiles without a problem.
However, when a vNext build (is this the name for the new build system?) is queued, it ignores completely the custom ruleset and just uses the StyleCop one (that is also included), which gives a bunch of warnings. Said warnings should not appear as the Custom RuleSet basically suppresses those warnings (ie: Warning SA1404: Code analysis suppression must have justification,
Warning SA1124: Do not use regions, etc)
As far as I have checked, there is no setting to specify the ruleset, and this works with XAML Builds. What is different in this new build system that is causing this? Is there a way to force/specify the Code Analysis Rule Set from the definition?
Thanks in advance for any help or advice on the matter.
Update/Edit
After debugging back and forth with the wonderful help of jessehouwing I must include the following detail on my initial report (that I ignored as I did not know that it was influential):
I am using SonarQube Analysis on my build definition.
I initially did not mention it as I did not know that it replaces the Code Analysis at Build Time (and not only when it "analyzes", as I thought).
If you are using the SonarQube tasks
The SonarQube tasks generate a new Code Analysis Ruleset file on the fly and will overwrite the one configured for the projects. These rulesets will be used regardless of what you've previously specified.
There is a trick to the naming of the rulesets through which you can include your own overrides.
More information on the structure can be found in the blog post from the SonarQube/Visual Studio team. Basically when you Bind your solution to SonarQube it will generate 2 ruleset files. One which will be overwritten during build, the other containing your customizations.
There is a toolkit/SDK to generate a SonarQube plugin for custom analyzers which allow you to import your rules into SonarQube, so it will know what rules to activate for your project(s).
If you're not using SonarQube
Yes you can specify the ruleset you want to use and force Code Analysis to run. It requires a couple of MsBuild arguments:
/p:RunCodeAnalysis=true /p:CodeAnalysisRuleset="PathToRuleset"
Or you can use my MsBuild helper extension to configure these settings with the help of a UI template:

TeamCity IntelliJ Inspections - Include Files in Inspection Scope

Question: How can I get TeamCity to run inspections against the 3 html files in the www root directory?
I'm working on a node.js project. The team are all using JetBrains IDEA based IDEs. We have shared our Inspection Profile and a Scope for them to run against.
We have just setup TeamCity and have a build configuration to run the Inspections. It is working identically for everything except the 3 html files directly under the "www" directory. The problem is that errors for those 3 files are reported in IntelliJ but not in TeamCity.
The only thing that appears to be different is the scope. IntelliJ uses scope defined in an xml file. TeamCity scope is set through the UI (build step form field "Include / exclude patterns"). TeamCity's scope syntax is different to IntelliJ's ...for the life of me I cannot get TeamCity to operate on the same scope!
Intended Scope
Here is a picture of the Project with the inspection scope underlined in green. We want to exclude libraries and the very root folder of config, but include everything else (i.e. everything we write).
TeamCity Scope
I have tried 2 strategies and both seem to work in IntelliJ and fail on TeamCity.
Attempt 1 - Include Only:
+:backend/**
+:tests/**
+:www/css/**
+:www/dist/**
+:www/images/**
+:www/*
Attempt 2 - Include entire www then Exclude:
+:backend/**
+:tests/**
+:www/**
-:www/components/**
-:www/components-unmanaged/**
-:www/data/**
-:www/images/**
IntelliJ Scope
In IntelliJ both work.
Attempt 1 - Include Only:
pattern="file:backend//*||file:tests//*||file:www/css//*||file:www/dist//*||file:www/images//*||file:www/index.html||file:www/loadsave.html||file:www/logical.html"
...more readable with some line breaks:
file:backend//*
||file:tests//*
||file:www/css//*
||file:www/dist//*
||file:www/images//*
||file:www/index.html
||file:www/loadsave.html
||file:www/logical.html
Attempt 2 - Include entire www then Exclude:
(file:backend//*||file:tests//*||file:www//*)&&!file:www/components//*&&!file:www/components-unmanaged//*&&!file:www/data//*&&!file:www/images//
...again, more readable with line breaks:
(
file:backend//*
||file:tests//*
||file:www//*
)
&&!file:www/components//*
&&!file:www/components-unmanaged//*
&&!file:www/data//*
&&!file:www/images//
References
https://confluence.jetbrains.com/display/TCD9/Inspections#Inspections-IdeaPatterns
the pattern must satisfy the following rules: must end with either **
or * (this effectively limits the patterns to only the directories
level, they do not support file-level patterns);
...
the include pattern has a special behavior (due to underlying
limitations): it includes the directory specified and all the files
residing directly in the directories above the one specified.
Other Thoughts: Differing Inspection Support
The only other thought I had was that perhaps TeamCity just plain doesn't support the HTML inspections category that IntelliJ does, or so some bizarre reason it refuses to assess .html files.
Software Versions
IntelliJ IDEA 2016.1.2 (Build #IU-145.972, built on May 14, 2016)
TeamCity Professional 9.1.7 (build 37573)

IntelliJ sees multiple ghost modules in the project

I have only one module in the project, named FilterWidget. Despite that, IntelliJ sees multiple "ghost" copies of it:
All these modules allow partially separate, partially shared setup, which creates a mess.
What is it and how to fix?
These are not ghost modules; these are modules representing individual source sets in your Gradle project. As described on the JetBrains Web site, IntelliJ IDEA starting with version 2016.1 creates a separate module for every source set in your Gradle project, in order to correctly resolve dependencies which are only used in one source set.