[NEW RELEASE] ShellCheck Plugin 1.0.0

(Sbaudoin) #1

Hello everybody,

I have released a new SonarQube plugin to analyze Shell scripts with ShellCheck:

Be aware that you must have ShellCheck installed on the machine you will be running the scanner. So the installation and execution procedure is as follows:

  1. Install the plugin in SonarQube
  2. Install ShellCheck on the machine where you are going to run the scanner
  3. Run the scanner against a project containing .sh files

Can you add this plugin to the Marketplace and the Plugin Library page, please?

(G Ann Campbell) #2


After a preliminary look at your project, I find that your documentation seems a bit thin. Is ShellCheck run as part of analysis, or must it be run beforehand? If the former, how does analysis know where to find ShellCheck in order to execute it? (And would it be possible just to bundle the tool into your plugin?) If the latter, what analysis parameter is used to specify the ShellCheck report location?


(Sbaudoin) #3


I agree, I was a bit too eager to release the plugin. So I have improved the doc: can you check it, please? The idea is to have ShellCheck to be installed first on the system that will run the scanner, and then the plugin will execute ShellCheck and process the output to identify violations. If the shellcheck command is not located in the PATH for whatever reason, you can set the path to the executable in the Sonar settings.

I’m not willing to embed the ShellCheck executable into the plugin because ShellCheck has its own roadmap and release cycle and can be very easily installed with most system package managers. There may be system dependencies that I do not know and would cause shellcheck to fail if I don’t manage them correctly. I followed the same approach for my Ansible plugin.

(G Ann Campbell) #4


I’ve done a little testing and have some feedback on that. But first…


Totally reasonable. It was worth asking. :slight_smile:

Now, on to the testing…

I noticed that all your rules are registered as Code Smells, even those I would expect to see as Bugs, such as SC1047,

'Expected ‘fi’ matching previously mentioned ‘if’.

Note that that’s verbatim. The ironically unmatched quote is yours. :wink:

This item, BTW, is an observation, not a deal-breaker.

I happen to have a set of shell scripts I use to speed up the routine parts of testing, so I had a project ready to hand. My directory contained nothing but .sh files and a .git directory. After analysis, I got this:
At the same time, the project does show up in the Issues page:

From the projects page, I get

So I deduce that you didn’t implement any metrics. If you’re going to declare and “own” the language, you have to provide at least the basic metrics. Otherwise… well, you see what happens.

On a not-entirely-unrelated note, there is a community analyzer in the marketplace that provides shell analysis (including metrics): i-Code CNES. Since you both declare the language, users won’t be able to use the two plugins together (server startup error). Perhaps you could collaborate…?


(Sbaudoin) #5


Thanks for this thorough feedback.

First, about the numerous code smells: this can easily be changed by configuration, but there are so many rules that I simplified the thing and set code smell as the default type. Sure, I can change the type for some rules but it’s not easy to identify them (thanks for reporting that SC1047 rule, by the way).

Second, I was not aware of the i-Code CNES plugin. As far as I can see the i-Code rules seem very specific to the CNES context, but sure I can see if we can collaborate. I’ll let you know what comes out. However, in the meantime, if we cannot use the same language (e.g. because i-Code is too specific and I do not want to depend on it), how can we move forward? Should I define another language (or just a new language key)?



(G Ann Campbell) #6


I didn’t actually say that.

There’s no rule that 2 plugins can’t declare the same language. There’s only the truth that you can’t run an analysis with both of the “shell” plugins loaded.

And actually, the startup failure occurs because both plugins declare Sonar way. If one or both of you renamed your profiles, startup should succeed. But again, analysis will fail.

So if you and the i-Code CNES folks can’t come to an agreement then I would hope that one or both of you would add a notice in your docs like

:warning: Not compatible with [the other guy]


(Sbaudoin) #7


I’m not moving forward a lot on this issue. So I can manage with having a profile named differently. But I have a problem with the language extension: is there a way to detect if a language with the same key already exists? It is possible to get the list of languages by querying the Web API but how to achieve this in the plugin code?


(Sbaudoin) #8

Forget about my question, I can find several reasons why what I’m trying to do is impossible. So let’s change strategy: is there a way to set a configuration parameter somewhere that would be accessible from the plugin code and that would tell me if I must register a language or not?

(G Ann Campbell) #9


I don’t think there is a way for you to conditionally declare the language. I guess you’ve made a good-faith effort to contact the maintainers of the i-Code CNES plugin(?) If so, then I’d say declare the language, add a warning to your docs, and move on with your life.


(Sbaudoin) #10


I can simply do that by checking a system property, but this requires that one sets this property (to disable my language) on the JVM in the SonarQube boot script. The question I have is: is that supported and if so is there a naming convention to following for such plugin-specific system properties?


(G Ann Campbell) #11


That’s really not, and more than we’d want to ask of the user.


(Sbaudoin) #12

OK. So an environment variable instead?

(G Ann Campbell) #13


If you really want to. But doing nothing on the coding side and simply adding a note in your docs would really be sufficient.


(Sbaudoin) #14

OK, thanks. I’m going to release a version 2.0.0 very soon.