simlock
병렬 코딩 에이전트가 동일 시뮬레이터를 놓고 충돌하지 않도록 제어 평면 제공
SonarQube는 코드 품질·보안 검토를 자동화하고 실용적인 코드 인사이트를 제공해 개발자가 더 빠르고 좋은 소프트웨어를 만들 수 있게 한다
SonarQube automates code quality & security reviews and provides actionable code intelligence so developers can focus on building better, faster.
개발 도구Java · ShellGitHub @SonarSource온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
Continuous Inspection
저장소 README에서 가져옴
README 전체를 불러오는 중입니다.
README 전문 보기 ↗SonarQube is the algorithmic verification platform for code quality and security. Its static analysis applies techniques such as symbolic execution and data and control flow analysis to inspect your code, find bugs, vulnerabilities, and structural problems, and tell you exactly what to fix and why, in your IDE, your pull requests, and your CI pipeline.
This repository holds the source of the SonarQube Community Build, the free, open-source edition of the SonarQube platform. It shares the same analysis used across the SonarQube product line.
AI writes code faster than teams can review it, creating verification debt: code reaching production before anyone has confirmed what it does. SonarQube applies the same consistent, explainable analysis to every line, whether a developer or an agent wrote it. Vibe, then verify: generate fast, then verify what reaches production. It is the verification stage of the Agent Centric Development Cycle, running in the outer CI verification loop to verify code before it merges.
The SonarQube platform analyzes more than 40 programming languages and frameworks; the Community Build supports a subset of them. Analysis is repeatable, auditable, and explainable: the same code always produces the same findings, every finding is traceable, and each one tells you what the problem is and why it matters.
SonarQube Server and SonarQube Cloud include everything in the Community Build and add:
Detect more
Analyze your whole workflow
Govern, report, and see across teams
Fix
Some capabilities are part of the SonarQube Advanced Security add-on. See the product line for details.
A Quality Gate is a pass-or-fail check on your new code. Set the standard once, and SonarQube enforces it automatically in every pull request and pipeline, so issues are caught before they merge rather than found in production.
The Community Build is free and open source. The wider SonarQube line applies the same analysis across your workflow:
Compare SonarQube plans and pricing to choose the appropriate product and deployment model.
Is the Community Build free? Yes. It is free and open source, and this repository is its source.
What is the difference between the Community Build and SonarQube Server? The Community Build is the free, self-managed engine. SonarQube Server and SonarQube Cloud are the commercial editions. They cover more languages and add branch and pull request analysis, software composition analysis (SCA), architecture management, advanced security with taint analysis (SAST), secrets detection, infrastructure as code (IaC) analysis, the SonarQube Remediation Agent for verified fix pull requests, and enterprise reporting. Some capabilities are part of the SonarQube Advanced Security add-on. See the product line for details.
Does it work on AI-generated code? Yes. SonarQube applies the same analysis to all code, whether a developer or an agent wrote it.
For support questions ("How do I?", "I got this error, why?", ...), please first read the documentation and then head to the SonarSource Community. The answer to your question has likely already been answered! 🤓
Be aware that this forum is a community, so the standard pleasantries ("Hi", "Thanks", ...) are expected. And if you don't get an answer to your thread, you should sit on your hands for at least three days before bumping it. Operators are not standing by. 😄
If you would like to see a new feature or report a bug, please create a new thread in our forum.
Please be aware that we are not actively looking for feature contributions. The truth is that it's extremely difficult for someone outside SonarSource to comply with our roadmap and expectations. Therefore, we typically only accept minor cosmetic changes and typo fixes.
With that in mind, if you would like to submit a code contribution, please create a pull request for this repository. Please explain your motives to contribute this change: what problem you are trying to fix, what improvement you are trying to make.
Make sure that you follow our code style and all tests are passing (a GitHub Actions build is executed for each pull request).
Willing to contribute to SonarSource products? We are looking for smart, passionate, and skilled people to help us build world-class code-quality solutions. Have a look at our current job offers here!
To build sources locally follow these instructions.
-x test to the gradle command (useful if you just want to build without running tests)Execute from the project base directory:
./gradlew build
The zip distribution file is generated in sonar-application/build/distributions/. Unzip it and start the server by executing:
# on Linux
bin/linux-x86-64/sonar.sh start
# or on MacOS
bin/macosx-universal-64/sonar.sh start
# or on Windows
bin\windows-x86-64\StartSonar.bat
If the project has never been built, then build it as usual (see previous section) or use the quicker command:
./gradlew ide
Then open the root file build.gradle as a project in IntelliJ or Eclipse.
| ./gradlew command | Description |
|---|---|
dependencies | list dependencies |
spotlessApply | fix source headers by applying HEADER |
wrapper --gradle-version <version> | upgrade wrapper |
The SonarQube UI (or webapp as we call it), is located in another repository: sonarqube-webapp.
When building the sonarqube repository, the webapp is automatically downloaded from Maven Central as a dependency, it makes it easy for you to contribute backend changes without having to care about the webapp.
But if your contribution also contains UI changes, you must clone the sonarqube-webapp repository, do your changes there, build it locally and then build the sonarqube repository using the WEBAPP_BUILD_PATH environment variable to target your custom build of the UI.
Here is an example of how to do it:
cd /path/to/sonarqube-webapp/server/sonar-web
# do your changes
# install dependencies, only needed the first time
yarn
# build the webapp
yarn build
cd /path/to/sonarqube
# build the sonarqube repository using the custom build of the webapp
WEBAPP_BUILD_PATH=/path/to/sonarqube-webapp/server/sonar-web/build/webapp ./gradlew build
You can also target a specific version of the webapp by updating the webappVersion property in the ./gradle.properties file and then building the sonarqube repository normally.
Historically our translations were stored in sonar-core/src/main/resources/org/sonar/l10n/core.properties, but this file is now deprecated and not updated anymore.
Default translations (in English) are now defined in the webapp repository, here:
https://github.com/SonarSource/sonarqube-webapp/blob/master/libs/sq-server-shared/src/l10n/default.ts
The format has changed but you can still have it as a .properties file format by running the following command:
cd /path/to/sonarqube-webapp/server/sonar-web
# install dependencies, only needed the first time
yarn
# generate a backward compatible .properties file with all the translation keys
yarn generate-translation-keys
Note that contributing extensions for translations into other languages still work the same way as before. It's just the source of truth for the default translations that changed.
Copyright (C) SonarSource Sàrl.
Licensed under the GNU Lesser General Public License, Version 3.0