[NEW RELEASE] ShellCheck Plugin 1.0.0

SonarQube Server / Community Build Plugin Development
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?

1 Like
2

Hi,

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?

Ā 
Ann

3

Hello,

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.

4

Hi,

Iā€™ve done a little testing and have some feedback on that. But firstā€¦

:+1:

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:
Selection_189
At the same time, the project does show up in the Issues page:
Selection_190

From the projects page, I get
Selection_191

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ā€¦?

 
Ann

5

Hello,

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)?

Thanks,

Sylvain

6

Hi,

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]
ā€¦detailsā€¦

 
Ann

7

Hi,

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?

Thanks

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?

9

Hi,

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.

Ā 
Ann

10

Hello,

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?

Thanks

11

Hi,

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

 
Ann

12

OK. So an environment variable instead?

13

Hi,

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

Ā 
Ann

14

OK, thanks. Iā€™m going to release a version 2.0.0 very soon.

15

when I start one test, I receive:

Error executing command: Cannot run program ā€œshellcheckā€: error=2, No such file or directory ERROR: Is the command installed and in the path? ERROR: Hint: run the scanner in debug mode to get the complete stack trace

How resolve this problem? :

16

I installed the plugin from sonar qube.
the sonar-shellcheck-plugin-2.4.0.jar jar is located inside the directory / opt / sonarqube / extensions / plugins