# mc1arke/sonarqube-community-branch-plugin: branch analysis and PR decoration for SonarQube Community > The plugin adds the branch and pull request features that SonarQube Community Edition leaves out. It does this with a javaagent and a patched web app, which is also where the upgrade pain lives. **mc1arke/sonarqube-community-branch-plugin** — A plugin that allows branch analysis and pull request decoration in the Community version of Sonarqube - Repository: https://github.com/mc1arke/sonarqube-community-branch-plugin - Stars: 2,867 · Forks: 610 - Language: Java - License: LGPL-3.0 - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/mc1arke-sonarqube-community-branch-plugin ## The gap this plugin fills in SonarQube Community Edition SonarQube's branch analysis and pull request decoration are documented as commercial-edition features. The Community Edition does not include them. That means a team running Community Edition can scan a main branch, but it cannot scan a feature branch as a branch, and it cannot post the analysis result back onto a pull request. The plugin's stated purpose is to support the features and parameters from the SonarQube branch and pull request documentation inside the Community version. It is aimed at teams that already run Community Edition, want per-branch quality gates and PR comments, and are not ready to move to Developer, Enterprise or Data Center Edition. The README is explicit that the plugin is not maintained or supported by SonarSource and that asking SonarSource or the Sonar Community forum for help with it will likely get the request closed or ignored. That is not a footnote. It defines the support model: GitHub issues on the repository, or channels like StackOverflow. ## How the javaagent and web app replacement work together The plugin is not a normal drop-in extension. Two mechanisms run at once. First, the plugin JAR is loaded as a Java agent into both the SonarQube web process and the compute engine process, which is how the server-side code gets patched to understand branches and pull requests. The README's install steps add two properties to conf/sonar.properties: sonar.web.javaAdditionalOpts and sonar.ce.javaAdditionalOpts, each pointing at the JAR inside extensions/plugins/ with a =web or =ce suffix. Second, the web UI is replaced wholesale: the release archive includes a sonarqube-webapp.zip, and the instructions say to replace the contents of the web directory in the SonarQube installation with the contents of that archive. The repository layout reflects this: there is a sonarqube-webapp directory and a sonarqube-webapp-addons directory, and the Dockerfile builds the web app with Node and yarn before copying the built output over /opt/sonarqube/web. So the plugin ships a patched front end plus a bytecode-level patch to the server. That is why installation touches three places (plugins, java options, web directory) instead of one. ## Installing the plugin manually and running a first branch scan For a manual install, the README says to either build the project or download a compatible release JAR and the associated sonarqube-webapp.zip, then copy the JAR into the extensions/plugins/ directory. After that, two javaagent lines go into conf/sonar.properties, one for the web process and one for the compute engine. The README gives these lines with a ${version} placeholder, so substitute the plugin version you downloaded. ```bash sonar.web.javaAdditionalOpts=-javaagent:./extensions/plugins/sonarqube-community-branch-plugin-${version}.jar=web sonar.ce.javaAdditionalOpts=-javaagent:./extensions/plugins/sonarqube-community-branch-plugin-${version}.jar=ce ``` The README then says to replace the contents of the web directory with the contents of the sonarqube-webapp.zip archive, start SonarQube, and accept the warning about third-party plugins. For the first real scan, the README's order matters: analyze the target branch first, then the pull request branch. On the target branch, the analysis needs the branch name set, and the README gives this property: ```bash sonar.branch.name = branch_name (e.g master) ``` For the pull request itself, the README points at the official pull request decoration guide and lists the three properties that must be set unless your CI auto-configures them. The README also warns that there must not be any sonar.branch properties on the pull request analysis. ```bash sonar.pullrequest.key = pull_request_id (e.g. 100) sonar.pullrequest.branch = source_branch_name (e.g feature/TICKET-123) sonar.pullrequest.base = target_branch_name (e.g master) ``` Before any of this, set sonar.core.serverBaseURL under /admin/settings. The README states this is needed for the links in the pull request comment to work. ## Docker Compose and the Helm chart path The repository ships a docker-compose.yml that pairs a SonarQube image with PostgreSQL 16. It uses the mc1arke/sonarqube-with-community-branch-plugin image, with image versions matching the upstream SonarQube image version, and reads SONARQUBE_VERSION from a .env file. The README's steps are to clone the repository, create a .env with SONARQUBE_VERSION defined, and run docker compose up. The compose file publishes port 9000, sets SONAR_JDBC_URL to jdbc:postgresql://db:5432/sonar with the sonar user, and defines named volumes for sonarqube_conf, sonarqube_data and the PostgreSQL data. The database service has a pg_isready healthcheck and the SonarQube service waits on it. One detail worth reading twice: the README notes that if you override SONAR_WEB_JAVAADDITIONALOPTS or SONAR_CE_JAVAADDITIONALOPTS in your container launch, you must re-add the javaagent configuration yourself, because the provided Dockerfile sets those variables. For Kubernetes, the README gives a values block for the official SonarQube Helm chart that enables community mode, installs the plugin JAR from the release URL, sets both javaAdditionalOpts keys, and adds an init container that downloads and unpacks sonarqube-webapp.zip into a mounted web directory. The init container uses busybox:1.37 and wget, and chowns the unpacked files to 1000:0. ## Version matching is the real operational constraint The README states that the plugin's major and minor versions match the SonarQube version it is compatible with, giving 25.4.0 of the plugin as compatible with SonarQube 25.4.x. It also states that older plugin versions are not guaranteed to work and that newer SonarQube versions are not guaranteed to work with previous plugin versions. Read that as a hard coupling rather than a soft recommendation. Every SonarQube upgrade becomes a plugin upgrade, and the plugin upgrade is not just a JAR swap: the web directory has to be replaced again with the matching sonarqube-webapp.zip, and the javaagent flags have to point at the new filename. The installation section adds its own warning: follow the installation instructions for the version you are installing by looking at the README on the relevant release tag, because instructions change between versions. The current README is not necessarily the right one for the release you downloaded. The release cadence visible in the repository is monthly or near-monthly, which suggests the maintainer tracks upstream SonarQube releases closely, but it also means there is a moving target to keep up with. ## The migration trap if you later buy a commercial edition This is the limitation that deserves the most attention. The README says the plugin has no official upgrade path for migrating from Community Edition to any commercial edition, and that if you plan to migrate your SonarQube data after using this plugin, some or all of your data may be lost because the compatibility between this plugin and the official SonarQube branch features is untested. So the plugin can be a good fit for a team that intends to stay on Community Edition, and a poor fit for a team that expects to move to Developer or Enterprise Edition later and wants to keep its history. The second limitation is support. There is no vendor behind it. SonarSource will not help, and the README says requests to SonarSource or affiliated channels are likely to be closed or ignored. The third is the installation surface itself: replacing the web directory and patching two JVM processes is more invasive than installing a normal plugin, and any locally customized web assets will be overwritten when you follow the install steps. If your organisation requires vendor-supported components in the build pipeline, this plugin does not qualify. ## How it compares to the commercial editions and to plain Community Edition The honest alternative is not another plugin. It is SonarQube Developer Edition or above, which includes branch analysis and pull request decoration as supported features with an official upgrade path and vendor support. The difference is not just money. With the commercial editions, the branch and pull request features are part of the product, so upgrades are SonarSource's problem, not yours, and there is no web directory to replace by hand. With this plugin, you get comparable capability on Community Edition but you own the upgrade path, the javaagent flags, and the web app swap. A second alternative is to stay on plain Community Edition and give up branch analysis entirely: scan only the main branch and accept that pull requests get no decoration. That is a real option for small teams where a single branch gate is enough. The plugin's value is concentrated in teams that need per-branch gates and PR comments, run Community Edition, and have the operational appetite to maintain a patched SonarQube instance. If that appetite is missing, the commercial edition is the lower-risk route even at its price. ## Licence and what to check before you deploy The repository is licensed under LGPL-3.0. Because the plugin is loaded as a javaagent into the SonarQube web and compute engine processes and also replaces the web application files, it modifies the behaviour of the SonarQube server rather than running as an isolated service. How LGPL-3.0 applies to that arrangement is a question for your own legal review; the README does not discuss licensing at all, and nothing here should be read as legal advice. Operationally, the checks that matter before deploying are: confirm the plugin's major and minor version matches your SonarQube version, read the README on that release tag rather than the master README, set sonar.core.serverBaseURL so comment links resolve, and decide in advance what happens to your data if you later move to a commercial edition. The last push to the repository was on 2026-08-27, and the most recent release listed is 26.5.0 from 2026-06-01, so the project is being updated, but the support model remains GitHub issues and community channels. ## Conclusion Adopt it if you run SonarQube Community Edition, want branch analysis and pull request decoration, and can accept that every SonarQube upgrade means matching the plugin's major and minor version, replacing the web directory, and re-testing the javaagent flags. Do not adopt it if you need an official upgrade path to a commercial edition, since the README warns that migrating data after using this plugin may lose some or all of it. Before deploying, verify the plugin version against your SonarQube version, confirm the javaagent lines in conf/sonar.properties, and check that sonar.core.serverBaseURL is set so comment links resolve. ## FAQ ### What are the limitations of SonarQube Community Edition that this plugin addresses? Community Edition does not include branch analysis or pull request decoration, which SonarQube documents as commercial-edition features. The plugin's stated purpose is to support the branch and pull request features and parameters from the SonarQube documentation inside the Community version. ### Is the mc1arke/sonarqube-community-branch-plugin free? The repository is licensed under LGPL-3.0, so the plugin itself is free to use under that licence. It is not maintained or supported by SonarSource, and support is only available through GitHub issues or channels such as StackOverflow. ### Which SonarQube version is the mc1arke/sonarqube-community-branch-plugin compatible with? The plugin's major and minor versions match the SonarQube version it is compatible with, for example plugin 25.4.0 works with SonarQube 25.4.x. Older plugin versions are not guaranteed to work, and newer SonarQube versions are not guaranteed to work with previous plugin versions. ### How do I install the mc1arke/sonarqube-community-branch-plugin with Docker? The plugin is distributed in the mc1arke/sonarqube-with-community-branch-plugin Docker image, whose image versions match the upstream SonarQube image version. The repository also provides a docker-compose.yml that reads SONARQUBE_VERSION from a .env file; clone the repository, create the .env, and run docker compose up. ### Why is there no pull request decoration after installing the plugin? The README says you must analyze the target branch before the pull request branch, and set sonar.pullrequest.key, sonar.pullrequest.branch and sonar.pullrequest.base on the pull request analysis unless your CI auto-configures them. It also warns there must not be any sonar.branch properties on the pull request analysis. ## Sources - [Issues](https://github.com/mc1arke/sonarqube-community-branch-plugin/issues) - [License: LGPL-3.0](https://github.com/mc1arke/sonarqube-community-branch-plugin/blob/master/LICENSE) - [mc1arke/sonarqube-community-branch-plugin on GitHub](https://github.com/mc1arke/sonarqube-community-branch-plugin) - [README](https://github.com/mc1arke/sonarqube-community-branch-plugin/blob/master/README.md) - [Releases](https://github.com/mc1arke/sonarqube-community-branch-plugin/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mc1arke-sonarqube-community-branch-plugin