# sonar-cnes-report turns a SonarQube server into editable docx, xlsx and markdown reports > sonar-cnes-report is a Java tool from CNES that exports SonarQube analysis as docx, xlsx, csv, markdown and text, either as a standalone JAR or as a SonarQube plugin, with custom templates and French or English output. It is a reporting layer over the web API, so its output is only as good as the analysis your SonarQube instance holds. **cnescatlab/sonar-cnes-report** — Generates analysis reports from SonarQube web API. - Repository: https://github.com/cnescatlab/sonar-cnes-report - Stars: 646 · Forks: 197 - Language: Java - License: GPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/cnescatlab-sonar-cnes-report ## A reporting layer over the SonarQube web API SonarQube is described as an open platform to manage code quality, and sonar-cnes-report's whole job is to take what that platform has measured and write it out as files. The description is precise: this program can export code analysis from a SonarQube server as a docx, xlsx, csv, markdown and text files. The primary language is Java, the project is GPL-3.0, and it comes from CNES, the French space agency, whose CatLab group is behind it. The problem it solves is a distribution one. A quality dashboard is a good tool for the people who live in it, and a poor one for the people who need a document. Auditors, quality managers, project sponsors and auditors in the software supply chain want a file they can attach to a process, and they want it in the format their own tooling reads. Producing a docx from a SonarQube server by hand is tedious enough that people stop doing it, and a project without those artefacts is a project whose quality is invisible outside the team that runs the server. The feature list makes the same point from a different angle: export code analysis as a set of files, export code analysis configuration, use custom templates, get a custom OpenXML report, get a dynamic pivot table with all issues, and export in French or English. The second of those is worth pausing on. Exporting the quality configuration used during the analysis, along with the results, is what makes a report auditable. A result without the profile that produced it is a number without a denominator, and this tool can capture both. ## Standalone JAR or a plugin inside SonarQube The tool can be used in standalone as a JAR executable with the command line, or as a Sonarqube plugin, and the two modes are documented separately. In standalone mode, no installation is needed. The README describes it as a portable Java application you can copy and run, and the only requirement is an up-to-date JRE, version 1.8 or newer. The quickstart is three steps: set up a SonarQube instance, run an analysis with sonar-scanner, maven, gradle or msbuild, and then execute cnesreport. In plugin mode, which has been available since version 2.2.0, you copy the jar with read rights for others into the plugin folder of SonarQube, which on Linux is a path like /opt/sonarqube/extensions/plugins, and restart SonarQube with sudo service sonar restart. The report then appears in the web interface under More and then CNES Report, where you pick a project. There is a wrinkle worth knowing in standalone mode. The quickstart tells you to give your jar read permissions for others, with chmod o+r on the file. The reason is implied by the plugin mode requirement of read rights for others, and it matters because a jar without it can be unreadable to the account that runs the analysis tooling. The default branch for the repository is dev, and the release history shows version 5.0.4 dated 2026-04-29, with 5.0.3 and 5.0.2 before it, while the last push was on 2026-05-21. ## The command line surface and what the flags actually control The tool prints its own help, and the README reproduces it. The usage line lists the options, and each one is short enough to read. The core four are the ones you will use every time. -p is the SonarQube key of the targeted project, -s is the complete URL of the targeted server, -t is the SonarQube user token of a user who has permissions on the project, and -o is the output path for the exported resources. Then there is a family of switches that turn individual outputs off, which is what makes the tool usable in a pipeline that only wants one artefact. -w disables report generation, -e disables spreadsheet generation, -f disables csv generation, -m disables markdown generation, and -c disables the export of the quality configuration used during the analysis. Three options point at templates. -r is the path to the report template, -x the path to the spreadsheet template and -n the path to the report template in markdown, and all three default to the internal template. That is the feature that makes the output genuinely yours rather than the tool's, and it is what allows the docx and xlsx files to carry your own house style, your logo and your own table structure. Two options handle context. -b selects a branch of the targeted project and requires Developer Edition or the sonarqube-community-branch-plugin, defaulting to the main branch, and -d sets the date for the report in yyyy-MM-dd format, defaulting to the current date. -l sets the language of the report, with values en_US and fr_FR, and -a records the name of the report writer. -h prints the help and -v the version. The simplest invocation therefore needs one option, and the README shows it exporting the report, the spreadsheet and the configuration for a public project from a local server using the default internal templates. ## Tokens, branches and the proxy flags Three details in the README will save you an afternoon if you read them first. The first is the token type. For a secured instance of SonarQube you provide a SonarQube user token with the -t option, and the README is emphatic in parentheses that a Global or Project Analyses Token is not sufficient. That is a real distinction in SonarQube's permission model, and a report run with the wrong kind of token fails in a way that looks like an authentication problem rather than a permission one. The second is the branch option. The -b flag exports the report for a specific branch of the project, and it needs either a commercial edition of SonarQube or the sonarqube-community-branch-plugin. On an open source instance without that plugin, a branch export is not available. The third is the proxy support, which the README frames as an enterprise feature available to all. Because the application uses the system proxy configuration, there is no extra parameter to set, but four Java properties have to be present: https.proxyHost, https.proxyPort, https.proxyUser and https.proxyPassword. If your JRE's proxy is not already set, you can pass them as Java flags on the command line, before the -jar argument, in the form the README shows. The logging story is also documented. You can have more detailed logs in the hidden directory .cnesreport, which should be created in your home directory at first launch, and the README suggests also looking at the SonarQube server logs, which it says can be very helpful in debugging a problem. That second point is worth taking seriously, since a report failure is often a server-side data problem rather than a client-side one. ## Running the simplest and advanced examples The examples are short, and each one isolates a scenario you are likely to hit. The simplest usage exports the report, the spreadsheet and the configuration for a public project from a SonarQube server on localhost, using the default internal templates, and the whole command is: ```shell java -jar sonar-cnes-report.jar -p projectId ``` The advanced standalone case adds a token, an explicit server URL and a custom report template: ```shell java -jar sonar-cnes-report.jar -t xuixg5hub345xbefu -s https://example.org:9000 -p projectId -r ./template.docx ``` Note the template argument at the end. That is the switch that turns the exported document from the tool's default layout into your organisation's, and it is a path to a docx file on the machine running the tool. The branch case is shorter still, and it is worth noticing that the README writes the jar name differently here, as cnesreport.jar without the hyphens: ```shell java -jar cnesreport.jar -p projectId -b dev ``` The proxy example shows the flags before the jar, which is the only order that works, since everything after -jar is passed to the application rather than to the JVM: ```bash java -Dhttps.proxyHost=https://myproxy -Dhttps.proxyPort=42 -Dhttps.proxyUser=jerry -Dhttps.proxyPassword=siegel -jar sonar-cnes-report.jar -t xuixg5hub345xbefu -s https://example.org:9000 -p projectId ``` If you have installed cnes-report in your sonarqube, the alternative route is the web interface: open it, click on CNES Report, then choose a project. ## The project layout and the packaging of the report assets The repository is a Maven Java project with a small JavaScript side. The top level holds a pom.xml for the Java build, a sonar-project.properties file, a src directory, a scripts directory, a package.json with a yarn.lock alongside, and a package-lock.json, plus the usual project files including CONTRIBUTING.md, COPYING and a pull request template. The JavaScript side is worth a note because it is not the report generator. The package.json is named sonar-cnes-report, licensed GPL-3.0, and its single script is a build step, node scripts/build.js, with a Babel setup for a react-app preset and a webpack toolchain with the babel, css and style loaders. The version recorded there is 5.0.0 while the release tags are at 5.0.4, so the two manifests are not kept in lockstep and the Java build is the one that produces the artefact. The plugin itself is a single jar, sonar-cnes-report.jar, and the mode you choose is a deployment decision rather than a build decision. That has a practical consequence: the same jar serves as a command line tool and as a plugin, so a team that runs reports from CI and a team that uses the SonarQube web interface can share the same file and the same templates. The project also tracks itself with SonarQube, since the README carries badges for the SonarQube quality gate, bugs, coverage and technical debt on the project fr.cnes.sonar:cnesreport, alongside a GitHub Actions badge for the Java continuous integration workflow. A reporting tool that analyses code quality being analysed by the same tool is a reasonable stance, though the badges measure the project rather than the reports it produces. ## Where sonar-cnes-report is the wrong tool The boundary is straightforward once you understand that the tool is a reader. First, it does not analyse anything. Every number in the report comes from a SonarQube server that has already run an analysis. If your pipeline has no analysis, this tool produces an empty or failing report, and the fix is to run sonar-scanner, maven, gradle or msbuild, not to adjust the report options. That is not a criticism of the tool, it is a description of where it sits. Second, it is not a dashboard. If what you need is per-issue browsing, live quality gates or trend charts for the team working on the code today, the SonarQube web interface is the right tool and this one is a distribution layer on top of it. The plugin mode exists precisely so that a SonarQube user does not have to leave the interface, which reinforces that the tool is aimed at producing artefacts rather than replacing the product. Third, the branch limitation is a licensing boundary as much as a technical one. Branch export requires Developer Edition or a community plugin, so on a plain open source instance with many active branches, the report is about the main branch and the team has to accept that. Anyone planning a per-branch reporting regime should check that before committing to the tool rather than after. The alternative approach, and it is a reasonable one, is to consume the SonarQube API directly and build your own reporting. The web API that this tool calls is the same one any script can call, and a team with a specific deliverable in mind, such as a version of the quality gate result inside an existing dashboard, may find that writing the generator is cheaper than bending templates. The difference in approach is that sonar-cnes-report ships the document templates, the OpenXML generation, the pivot table and the bilingual output as a finished package, and asks only for your own template files when you want to change the layout. ## Conclusion Adopt sonar-cnes-report if your organisation needs SonarQube results as editable office documents rather than a web dashboard, since the docx and xlsx outputs are built from OpenXML templates you can replace, and the plugin mode puts a report behind the More menu of an existing server. Do not adopt it as a replacement for the SonarQube interface or as a scanner, because it reads analysis results through the web API and generates nothing itself. Verify first that the SonarQube version you run accepts the plugin, that the token you use is a user token rather than a Global or Project Analysis token, which the README says is not sufficient, that your JRE is at least 1.8, and that a branch export matches your licence, since the -b option requires Developer Edition or the sonarqube-community-branch-plugin. ## FAQ ### How do I run sonar-cnes-report for the first time? Set up a SonarQube instance, run an analysis with sonar-scanner, maven, gradle or msbuild, then execute the tool. The minimal standalone command is java -jar sonar-cnes-report.jar -p projectId, and the only requirement is an up-to-date JRE, version 1.8 or newer. ### Which token do I need to export a report from a secured SonarQube? You need a SonarQube user token of a user who has permissions on the project, passed with the -t option. The README states explicitly that a Global or Project Analyses Token is not sufficient. ### How do I install sonar-cnes-report as a SonarQube plugin? Copy the sonar-cnes-report.jar with read rights for others into the plugin folder of SonarQube, which on Linux is a path like /opt/sonarqube/extensions/plugins, then restart SonarQube with sudo service sonar restart. The report appears in the web interface under More and then CNES Report. ### Can sonar-cnes-report export a specific branch of a project? Yes, with the -b option, but it requires a commercial edition of SonarQube or the sonarqube-community-branch-plugin. Without one of those, the report defaults to the main branch. ### Which output formats does sonar-cnes-report support? It exports code analysis as docx, xlsx, csv, markdown and text files, and it can also export the quality configuration used during the analysis. Individual outputs can be turned off with the -w, -e, -f, -m and -c options, and custom templates can be supplied with -r, -x and -n. ## Sources - [cnescatlab/sonar-cnes-report on GitHub](https://github.com/cnescatlab/sonar-cnes-report) - [Issues](https://github.com/cnescatlab/sonar-cnes-report/issues) - [License: GPL-3.0](https://github.com/cnescatlab/sonar-cnes-report/blob/dev/LICENSE) - [README](https://github.com/cnescatlab/sonar-cnes-report/blob/dev/README.md) - [Releases](https://github.com/cnescatlab/sonar-cnes-report/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cnescatlab-sonar-cnes-report