I have just released a new version of the Sonar Cloudformation Plugin:
plugin description: Cloudformation Plugin for SonarQube, support cfn-nag rules
version 1.0.2 changes : Update dependency com.fasterxml.jackson.core:jackson-databind to v2.10.0.pr2
The check sweep of the requirements looks good. I’ve asked for some changes on your PR.
For initial Marketplace entry I need to test. Can you provide a project that has a report file available? I’m too lazy to be eager to install all the underlying tooling.
I’ve had a chance to analyze with your test files (thanks!). First, analysis worked well, and your rules look good.
There are a couple things that need addressing:
You appear to have defined Cloudscan as a new language(?). At least it shows up as such on the Quality Profiles page and on the Rules page. Since we’re actually dealing with .yml files here, then these need to be treated as YAML rules, and your default profile needs to show up under YAML.
Additionally, I see that you’ve added two new administration categories under General settings: Cloudformation, and Sonar cloudformation plugin. Since these are both about subsets of YAML files, I think they should be moved under the YAML category.
One problem with not defining a separate language is that it is not possible to define a specific quality profiles. So if I have a default yaml quality profile I will need to add all cloudformation rules there as well.
Cloudformation is a DSL in yaml format, so the rules above only apply to a very small subset of yaml.
Any other workaround to be able to have a specific quality profiles without a language ?
You don’t have to have your own language to define a profile.
I’m struggling to recall which “external analyzers” define extra profiles for their languages (maybe FindBugs?) but I believe the PHP analyzer provides multiple profiles. Both are open source, so you could take a page out of their books.
What you can’t do without your own language is make your profile the default, but as you say your rules apply to only a subset of YAML files, so you wouldn’t want to do that anyway.
Been considering changing the plugin to use YAML category, to adhere to marketplace requirements
One of the problems is that cfn-nag that is used to generate the report is supporting “The path can be a directory or a particular template. If it is a directory, all *.json, *.template, *.yml and *.yaml files underneath there recursively will be processed.”
So would either require either sonar json or yaml plugin to be installed, depending on what format for cloudformation that is used.
I’m a little confused. Are you asking for advice on what direction to go in making changes or announcing that you’ve made changes and requesting re-consideration for the Marketplace?
In fact, a plugin can declare rules for multiple languages. The iCode CNES plugin is an example; it offers rules for both Fortran and Shell. IIRC it declares/owns both of those languages, but I’m guessing the principle is transferable. The hard part is the dependencies. I guess you don’t want to declare dependencies on both languages?
Alternately… What I’m reading is that it’s the underlying tool that reads the files:
So the plugin itself doesn’t need to be passed those files for analysis…
You do however, need to be able to raise issues on them but the Java plugin is a nice example of raising issues on files in a language it doesn’t own and that (in previous versions of SQ) may or may not be recognized by the server: it analyzes pom files in addition to Java and it works even in the absence of the XML analyzer IIRC.
Of course, to raise issues, you need rules and so then we’re back to needing a language. However, it’s possible that External Issues (essentially rule-less issues) could fit the bill here. Several of the built-in analyzers automatically handle rule reports for external analyzers. Again, the Java analyzer might be a model; I believe it now automatically imports reports from several other tools and raises external issues from those reports.
TBH I’m not 100% sure about being able to raise external issues on unrecognized file types (my testing of this feature was a very long time ago…), but a 5-minute test with a manually ginned-up external issues report would prove it out.
So what that brings us to is:
run the tool to get its report on whatever files it finds
parse the report to raise external issues on files of unrecognized types that you may need to do some work to grab manually (Java analyzer’s pom analysis is the example here)
The down side of this is that with external issues you can’t manage what rules are in the profile and thus which issues are raised. But if that’s acceptable it might be the way to go.
