[NEW RELEASE] Sonar Cloudformation plugin 1.0.2

Hi,

I have just released a new version of the Sonar Cloudformation Plugin:

best regards

Hi,

Is the implication here that you’d like the plugin to be included in the Marketplace?

 
:slightly_smiling_face:
Ann

Hi,

If it is possible I would like the plugin included in the Marketplace ?

Have added
PR in sonar-update-center-properties repo: https://github.com/SonarSource/sonar-update-center-properties/pull/50

The plugin complements the yaml plugin, since cloudformation templates analyzed by cfn-nag always are in yaml format.

Best regards James

Hi James,

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. :smiley:

 
Ann

hi,

The project itself contain some report files used for test https://github.com/Hack23/sonar-cloudformation-plugin/blob/master/src/test/resources/cfn-nag-scan.nagscan , result of cfn-nag on https://github.com/Hack23/sonar-cloudformation-plugin/blob/master/src/test/resources/CloudTrailAllAccounts.yml .

Please let me know if it’s enough or I can create another sample project.

best regards James

Example project using the plugin https://www.hack23.com/sonar/project/issues?id=com.hack23.cia%3Acia-all&languages=cfn&resolved=false

Hi James,

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.

 
Ann

Thanks for the feedback, will resolve the issues and release a new version during the weekend.

best regards James

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 ?

best regards James

Hi James,

You don’t have to have your own language to define a profile. :smiley:

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.

 
Ann

Hi,

Thanks for all the feedback, but will close my pull request for marketplace.

Like having a default profile for cloudformation, changing this would make it harder to use the plugin for my own usecases.

best regards

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.

Been releasing https://mvnrepository.com/artifact/com.hack23.sonar/sonar-cloudformation-plugin

Demo Sonarqube quality profile : https://www.hack23.com/sonar/profiles/show?language=cfn&name=Cloudformation+Rules

Demo Sonarqube quality rules : https://www.hack23.com/sonar/coding_rules?languages=cfn

Demo Sonarqube quality issues : https://www.hack23.com/sonar/project/issues?id=com.hack23.cia%3Acia-all&languages=cfn&resolutions=WONTFIX

best regards James

Hi James,

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?

 
Thx,
Ann

Hi Ann,

Sorry for being unclear, asking for advice so I know how to progress.

Started to look at https://github.com/spotbugs/sonar-findbugs/blob/master/src/main/java/org/sonar/plugins/findbugs/FindbugsPlugin.java , on how to extend other languages.

Do you think I need to duplicate the rules/quality profile for both json,yaml ?

Also unsure on how I define that json/yaml plugins are required.

best regards James

Hi James,

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.

 
HTH,
Ann