Marketplace, Plugins, Extension Risks, and Compatibility Management: Configuration, Design Patterns, and Trade-Offs

1. Design principle: prefer the smallest extension boundary that solves the problem

A server plugin is the most tightly coupled option because SonarQube must load and maintain it across server upgrades. If the required capability can be obtained from a built-in analyzer, that usually has the smallest compatibility surface. If an external tool already owns the analysis, importing its report can preserve tool ownership without loading its code into SonarQube. If the capability is orchestration rather than analysis, keep it in CI instead of extending the server.

2. Built-in analyzer vs plugin vs external report vs CI tool

3. Marketplace convenience versus manual governance

Community Build Marketplace is useful because it exposes installed plugins, compatible choices, and available updates. It also makes accidental “click and restart” changes easy. A governed environment should still create a change record before the click: exact plugin/version, compatibility evidence, source/release, checksum or signature evidence where available, license, expected capability, maintenance window, baseline, rollback, and owner.

Manual installation makes artifact custody explicit and is required by current commercial SonarQube Server documentation. Manual does not automatically mean safer: downloading a mutable URL without checksum verification is weaker than a well-governed Marketplace workflow. The design goal is evidence and reproducibility, not “UI bad, shell good.”

4. Pin the plugin set as configuration data

Treat installed plugins like a lockfile. The file should be reviewed in the same change as the SonarQube upgrade plan.

sonarqube:
  release: 26.9.0.129388-community
plugins:
  - key: example
    version: 1.2.3
    artifact: sonar-example-plugin-1.2.3.jar
    sha256: "<64-hex-digest>"
    source: "<immutable-release-url>"
    license: "Apache-2.0"
    compatibility_evidence: "current plugin version matrix checked 2026-09-08"
    owner: platform-quality
    required_by:
      - "synthetic-language-fixture"
    rollback: "remove artifact, restart, run baseline smoke checks"

A floating URL such as .../latest/download/plugin.jar is not a lockfile. Neither is a Docker/Helm configuration that downloads unversioned plugins during every startup.

5. Plugin API compatibility is a contract, not a guess

Since SonarQube 9.5 the Plugin API has its own release stream. Plugin metadata can declare a minimum Plugin API runtime version, and SonarSource publishes mappings between SonarQube releases and Plugin API versions. Within a Plugin API major line, forward compatibility is the goal, but an operator should still use the current matrix and plugin release notes rather than extrapolating.

When the SonarQube core release changes, rebuild the compatibility table before the server upgrade. The question is not “did this JAR work last year?” but “does the exact plugin version support the target SonarQube release, and is a maintained upgrade path available?”

6. Transitive dependencies and licenses belong in the review

Plugins can package third-party libraries in their JAR. A plugin’s own license does not automatically describe every bundled dependency. At minimum:

• review the publisher’s dependency/SBOM information if available;
• inspect source/build metadata such as Maven dependency trees for an open-source plugin;
• record licenses and known conflicts relevant to your organization;
• treat opaque binary-only plugins as a stronger trust decision;
• re-review dependencies when the plugin version changes.

Do not copy arbitrary JARs into a running service merely because antivirus finds no malware. Dependency risk includes compatibility, licensing, maintainership, and latent vulnerabilities as well as malicious code.

7. Scanner-side optimization can expose dependency mistakes

Current plugin guidance supports Plugin-RequiredForLanguages, which lets SonarQube avoid downloading analyzer/plugin code to scanners that do not need it. Plugins that extend a base analyzer should declare required languages correctly; otherwise a plugin can be downloaded when its base analyzer is absent and fail with dependency/class-loading errors. This is another reason to prefer maintained plugins whose manifests follow current API guidance.

8. Plugin upgrade sequence

1. Freeze the current server/plugin inventory and preserve checksums.
2. Read SonarQube target release notes and plugin version matrix.
3. For each plugin: keep, upgrade, replace with built-in/external integration, or remove.
4. Test the complete target set on a restored disposable/staging instance—not by copying the production database into an uncontrolled environment.
5. Run startup, scanner, Compute Engine, and project smoke evidence.
6. Only then plan the production maintenance change.

9. Single node versus Data Center

10. Worked decision table

11. Analysis evidence remains independent of plugin governance

When a plugin participates in analysis, preserve the same chain used throughout this course: scanner process result, report upload, report-task.txt/ceTaskId, Compute Engine completion, analysis result, Quality Gate, CI job status, and provider decoration. A pinned plugin inventory explains which executable extension set produced the result; it does not collapse those states into one success flag.

Knowledge check

Official references and version notes

• Community Build — Installing a plugin — Marketplace/manual paths, compatible JAR requirement, extensions/plugins, Docker/Kubernetes guidance, restart and uninstall behavior.
• Community Build — Using Marketplace — installed/compatible plugin discovery, internet/proxy behavior, Administer System requirement, pending install/update/uninstall and restart.
• Community Build — Plugin version matrix — current plugin-to-Community-Build compatibility table.
• Community Build — Plugin basics — Plugin API, scanner/Compute Engine/web extension points, manifest metadata, dependencies and Plugin-RequiredForLanguages.
• Community Build — Performing the update — install compatible third-party plugins for the target release instead of blindly copying old plugin folders.
• SonarQube Server — Installing a plugin — current commercial manual-install model and Data Center application-node consistency/maintenance rules.
• Sonar Plugin API repository — independent Plugin API release stream and SonarQube ↔ Plugin API compatibility mappings.
• Official SonarQube Docker image tags — exact 26.9.0.129388-community image used by the checkpoint.