Deploying to the Marketplace

SonarQube Server / Community Build Plugin Development
,
1

Hey SonarSource Community!

If you have developed a SonarQube plugin, and it meets the requirements, we can consider adding it to the SonarQube Marketplace.

This helps users not only find your plugin but also be alerted to updates.

Requirements

Your plugin needs to meet the following requirements to be considered for inclusion in the Marketplace.

  1. Your plugin is open-source
    1. Source is freely accessible
    2. The license is a known FLOSS one (check the list provided by the Open Source Initiative)
    3. There’s a public issue tracking system
    4. Documentation is available online in English
    5. Binaries of each version are accessible somewhere
  2. Releases follow open source conventions. For each release, the following must be available:
    1. release notes that reflect all significant changes in the version
    2. plugin jar
  3. The key of your plugin must be:
    1. short and unique
    2. lowercase (no camelcase)
    3. composed only of [a-z0-9]
    4. related to the name of your plugin
    5. not just the name of a language (e.g. cannot be java, rust, js/javascript, …)
      examples of good keys: motionchart, communityphp, scmactivity
  4. The description of your plugin must not be misleading in terms of content (the code needs to do pretty much what the name and description say it does).
  5. On initial entry into the Marketplace, SonarSource staff will test the plugin to verify reasonable functionality and quality. SonarSource staff must be provided with the necessary means to do this testing without the need to sign any agreements or fill out any forms. Ideally, the means to do this testing will be made available to the community at large, with the same lack of restrictions.
  6. Your plugin does not compete with existing or soon-to-be-released SonarSource products (sorry, but we gotta pay the bills somehow).
  7. It is analyzed on SonarCloud and the quality gate is green when doing a release.
  8. It is compatible with the platform requirements (e.g. it runs on the minimum listed JRE).
  9. If your plugin adds analysis of a language that is not analyzed by SonarQube you must provide the NCLOC and NCLOC_DATA metrics, which are both required for a consistent user experience. You can take a look at how those metrics are provided for Java (NCLOC, NCLOC_DATA).
  10. Your plugin must be aligned with the goal of the SonarQube platform: management of the technical debt and the quality of the code.
  11. Last but not least: your plugin must be - in our judgment - in the best interests of SonarQube users. That includes but is not limited to:
    1. no export of files to other servers / services from within SonarQube or during SonarQube analysis. If that needs to be done, it must be handled explicitly by the user, presumably before analysis.
    2. clear, helpful docs, definitions &etc.
    3. non-confusing UI/UX choices

:exclamation: To be more precise: every feature of SonarQube is tied to the code, so if your plugin provides data that can’t be attached to a source or a test file, then there are chances that your plugin won’t be accepted in the Marketplace

If your plugin meets these requirements, feel free to start a new thread here in the Plugin Development category of the Community Forum requesting inclusion. This thread should include:

  • plugin description
  • plugin home page URL
  • plugin project homepage on SonarCloud
  • the link to a PR adding a file for your plugin to the sonar-update-center-properties repo, and the elements of a “new release” announcement, listed below.

We reserve the right to exclude from the Marketplace plugins that we feel would be a dis-service to the community.

Announcing new releases

When you’ve got a new release that should be published in the Marketplace, please create a PR on the sonar-update-center-properties repo updating the file for your plugin with the data for your new release. The PR description should include a link to your plugin’s SonarCloud project dashboard so that we can check the quality gate status.

Someone from SonarSource will review your PR and perform the manual steps to make the version available in the Marketplace.

Suggestions to manage your plugin development

A project hosted in a GitHub repository can easily meet the requirements:

  • Sources are on Git - and you can easily configure them to be built by Travis CI
  • GitHub Issues can be used as a bug tracking system
  • GitHub Wiki or README.md can be used to write the documentation
  • GitHub Releases can be used to publish your binaries

You can obviously use this Community to ask for feedback on your plugin. You may want to post an RFF (Request for Feedback) before a release although it is not required. If you do, please close the thread before final release with a “feedback period closed” notice.

Plugin deprecation / removal

Occasionally, there’s a need to deprecate a plugin. Typically for one or more of the following reasons:

  • The functionality is obsolete or relies on deprecated platform functionality.
  • It’s no longer maintained by its authors and is buggy.
  • It’s no longer compatible with supported versions of the SonarQube platform.
  • It contains a known vulnerability.

In such cases, the plugin is removed from the Marketplace.

Changes or deprecation due to new native support

SonarSource occasionally adds support for new languages. If there is already a community plugin supporting the new language, we will contact the maintainer(s) to request the following in order to avoid conflicts for users:

Dropping those things will allow the plugin to continue offering its core value to users while offloading the “grunt work” to SonarSource. If these changes cannot be coordinated with the plugin maintainer(s) then we will be forced to deprecate / mark the plugin incompatible with new SonarQube versions so that users aren’t negatively impacted during analysis.

FAQ

Q. Where should the jars be posted for download?
Up to you. If you’re using GitHub to host your source code, then the easiest thing to do is create a project release and post downloads there.

Q. What should the release notes look like?
In the best case, it will be a publicly accessible list of work tickets handled in the version, similar to what you can get from Jira or GitHub Issues. At minimum, it will be an outline of the work done. In either case, it must reflect all significant changes.

4 Likes