The GitHub integration is disabled. Please ask an administrator of this project to enable it.
so seems like there is another codacy user which is called “infrastructure” that has the integration enabled. Is the Github user openmrs-bot now codacy user “infrastructure”? @burke maybe you know this
Ok. So, it looks like my following the steps above for openmrs-bot created the /infrastructure/ path on codacy. I didn’t know @pascal had already set up an account (org?) on codacy. I did check for any shared infrastructure credentials for codacy.com first, but didn’t see any, so just authenticated as openmrs-bot via GitHub.
We can certainly (hopefully) delete the “infrastructure” account set up for openmrs-bot and move it under /openmrs/, but it looks like @pascal will need to do that, since I don’t know how the /openmrs/ codacy account is set up (I can’t find shared credentials via LastPass or any mention of codacy on the IT wiki).
Sorry guys, I’ve just noticed I’m actually added to openmrs project admins on codacy. I’ve added burke (by your openmrs e-mail) to the project. @burke, you should be able to set up the integration now with openmrs-bot. Please disable the one in the infrastructure project.
I just wanted to point out, that the warning is coming from PMD and not checkstyle. It should be suppressible by adding a ruleset.xml file, which codacy should find. See [0] & [1]
we are using checkstyle, the rules are in the repo which we need to load into codacy (as codacy has an autoload feature but it only works when the file is in the root of the repo). also I see we have different rules for webapp which I dont think works in codacy.
the issue you are having is because codacy doesnt take into account our checkstyle suppression rules which are in a separate file. The workaround (which is not ideal) I just applied until I know of some other solution is that I added the api/src/test and web/src/test folders in the codacy UI to the ignored folders so this will help with your and other PRs.
currently we are having a bit of a mixup. @burke can you please remove the infrastructure user/account you created for the openmrs-bot (since this one currently has the github PR integration and uses other rules; and does not ignore the test directories).
I doubt that Sonar is the culprit of the infrastructure problems (at least JIRA was crashing because out of memory problems, and RAM is not expensive ).
Anyway, SonarQube is also available in the cloud, free for OS projects. And IMHO the UI is better than Codacy’s
I personally don’t mind if developers prefer Sonar or Codacy, or even both.
But in all fairness, sonar is not causing any big harm to our infrastructure, indeed. If you tell me that we can have the same software for free in the cloud, with all the features we need, I’d totally prefer that
A few comments why Codacy is better than Sonar in our case:
Currently Sonar is setup only for openmrs-core master. The full analysis takes ~40 minutes. We can afford to run it only every 24 hours. Doing it every commit could easily eat up all our CI agents and we would wait for other builds way too long. See https://ci.openmrs.org/browse/SON-OPENMRSCOREMASTER/latest. There’s an incremental analysis option for PRs, which is faster, but it cannot be used for analysis of the master branch since it doesn’t persist results in Sonar. Codacy on the other hand can be run every commit and every pull request and we get results in a few minutes.
Given the above it is unrealistic to enable Sonar for our modules. Enabling Codacy for modules is no brainer and doesn’t require any additional configuration other than adding a project to Codacy.
Sonar analysis even when using the cloud service is done on our CI (by maven sonar plugin). Basically the cloud service is just for storing/presenting results and setting up rules. Codacy analysis is done entirely on their infrastructure.
Codacy supports automatic loading of rules files (be it checkstyle, eslint, …) from the ROOT of the repository. We currently have 2 checkstyle files one for openmrs and one for webapp. Codacy expects it to be called checkstyle.xml and only loads one from the root directory. Please review my suggested solution so I can implement this:https://issues.openmrs.org/browse/TRUNK-5080 which will sync codacy’s rules with our checktsyle.xml
Codacy does not support the checkstyle suppression filter which uses the checkstyle-suppressions.xml. I also checked https://docs.codeclimate.com/docs/checkstyle which doesnt state anything that suggest they do support this. I asked their support and am waiting. This feature as far as I see is only possible with SonarQube since it collects the report from the maven checkstyle plugin where this suppression filter is configurable. Current solution: codacy (in their UI) is configured to ignore test classes entirely.
I added another task to update our maven checkstyle plugin which is very outdated: https://issues.openmrs.org/browse/TRUNK-5081 as part of this we could update our checkstyle.xml rules if anyone has suggestions.
If we are not happy with codacy we can still switch to another provider later or stick with SonarQube since they are (after #1 is done) all based on the same checkstyle.xml rules, at any rate we should clean this up