If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/SonarSource/sonarqube shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1w ago
• 29+ active contributors
• Distributed ownership (top contributor 25% of recent commits)
• LGPL-3.0 licensed
• CI configured
• Tests present
• ⚠ LGPL-3.0 is copyleft — check downstream compatibility

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live SonarSource/sonarqube repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/SonarSource/sonarqube.

What it runs against: a local clone of SonarSource/sonarqube — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in SonarSource/sonarqube | Confirms the artifact applies here, not a fork | | 2 | License is still LGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 38 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of SonarSource/sonarqube. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/SonarSource/sonarqube.git
#   cd sonarqube
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of SonarSource/sonarqube and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "SonarSource/sonarqube(\\.git)?\\b" \\
  && ok "origin remote is SonarSource/sonarqube" \\
  || miss "origin remote is not SonarSource/sonarqube (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(LGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"LGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is LGPL-3.0" \\
  || miss "license drift — was LGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/XooPlugin.java" \\
  && ok "plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/XooPlugin.java" \\
  || miss "missing critical file: plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/XooPlugin.java"
test -f "plugins/sonar-education-plugin/src/main/java/org/sonar/education/EducationPlugin.java" \\
  && ok "plugins/sonar-education-plugin/src/main/java/org/sonar/education/EducationPlugin.java" \\
  || miss "missing critical file: plugins/sonar-education-plugin/src/main/java/org/sonar/education/EducationPlugin.java"
test -f "plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/checks/Check.java" \\
  && ok "plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/checks/Check.java" \\
  || miss "missing critical file: plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/checks/Check.java"
test -f "gradle.properties" \\
  && ok "gradle.properties" \\
  || miss "missing critical file: gradle.properties"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 38 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~8d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/SonarSource/sonarqube"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

SonarQube is a server-side platform for continuous code inspection that analyzes source code across Java, Python, JavaScript, and 20+ other languages to detect bugs, vulnerabilities, code smells, and coverage gaps. It provides a Quality Gate mechanism to enforce code quality standards and prevent regressions, enabling teams to achieve 'Clean Code' by systematically improving code health on every commit. Gradle-based monorepo: core SonarQube engine in the root with buildSrc/ containing custom build plugins (BlackBoxTest.groovy, LicenseReader.groovy). plugins/ subdirectory holds optional extensions like sonar-education-plugin. Webapp source lives separately (github.com/SonarSource/sonarqube-webapp). Dual CI model: local Gradle builds + GitHub Actions orchestration. Heavy use of Protobuf code generation (com.google.protobuf plugin).

Enterprise development teams and platform engineers who need centralized code quality governance across polyglot codebases. DevOps leads implementing CI/CD pipelines with quality gates. Technical architects ensuring architectural compliance. Development teams seeking to shift left on security and maintainability issues.

Highly mature production system: 33MB+ of Java code across a well-structured monorepo, JDK 21+ requirement, comprehensive CI/CD via GitHub Actions (see .github/workflows/build.yml), active development with dependency management via Gradle 8+. Multiple consumer-facing plugins (see plugins/sonar-education-plugin/) indicate long-term maintenance and ecosystem investment. SonarSource backs this commercially.

Low immediate risk but dependency complexity: excludes eddsa globally (configurations.all block in build.gradle), requires exact JDK 21+ (strict version check), monorepo size means local builds are heavyweight. Main risk is breaking changes on major version bumps—check GITHUB_REF_NAME logic for branch-based release patterns. Community contributions explicitly discouraged per README ('not actively looking for feature contributions').

No recent commit data visible, but build.yml suggests continuous integration on commits/PRs. Plugin ecosystem is active (multiple sensors in sonar-education-plugin). BOM (Bill of Materials) generation enabled for main branches and nightly builds—indicates supply-chain security focus. Version tracking via buildNumber property suggests release automation.

git clone https://github.com/SonarSource/sonarqube.git
cd sonarqube
# Ensure JDK 21+ is active
java -version
# Build the project
./gradlew build
# Or use the provided shell script
bash build.sh

Daily commands:

# Build the distribution
./gradlew build
# Start local debug server (if available)
bash debug-server.sh
# Or manually start SonarQube server (check docs/ for deployment guides)

• build.gradle — Root build configuration defining all dependencies, plugins, and Java 21 requirement—essential for understanding the entire project structure and build process.
• plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/XooPlugin.java — Core plugin entry point that registers sensors, rules, and language definitions—foundation for how SonarQube discovers and executes analysis.
• plugins/sonar-education-plugin/src/main/java/org/sonar/education/EducationPlugin.java — Secondary plugin demonstrating educational rule integration patterns and sensor registration for contextual code analysis.
• plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/checks/Check.java — Base abstraction for quality rules—every contributor must understand how rules are defined and executed in SonarQube.
• gradle.properties — Gradle configuration with version properties and build settings—critical for reproducible builds across the team.
• .github/workflows/build.yml — CI/CD pipeline definition—shows how the project is tested and packaged on every commit.

Add a New Quality Rule

1. Create a new Check class extending Check.java in plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/checks/ (plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/checks/Check.java)
2. Register the check in the RulesDefinition by adding it to the rules list with metadata (name, severity, description) (plugins/sonar-education-plugin/src/main/java/org/sonar/education/EducationRulesDefinition.java)
3. Add the check to the active quality profile (e.g., Xoo3QualityProfileDefinition) to enable it by default (plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/Xoo3QualityProfileDefinition.java)
4. Write a test in the corresponding test directory (e.g., EducationRulesDefinitionTest) to validate registration (plugins/sonar-education-plugin/src/test/java/org/sonar/education/EducationRulesDefinitionTest.java)

Add a New Sensor for Custom Metrics

1. Create a new Sensor class in plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/ implementing SensorDescriptor (plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/coverage/AbstractCoverageSensor.java)
2. Implement the execute() method to read files and call context.newIssue() or context.newMeasure() to report findings (plugins/sonar-education-plugin/src/main/java/org/sonar/education/sensors/EducationRuleSensor.java)
3. Register the sensor in the plugin's addExtensions() method (e.g., XooPlugin.java or EducationPlugin.java) (plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/XooPlugin.java)
4. Write a test extending SensorTestCase to verify sensor behavior and issue reporting (plugins/sonar-education-plugin/src/test/java/org/sonar/education/sensors/EducationSensorTest.java)

Create a New Test Language Plugin

1. Create a new plugin class in plugins/ extending SonarPlugin and override the getExtensions() method (plugins/sonar-education-plugin/src/main/java/org/sonar/education/EducationPlugin.java)
2. Define a Language class specifying language key, name, and file suffixes (e.g., Xoo.java) (plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/Xoo.java)
3. Create a RulesDefinition class to declare rules specific to the language (plugins/sonar-education-plugin/src/main/java/org/sonar/education/EducationRulesDefinition.java)
4. Create sensors to execute analysis logic and save results via SensorContext (plugins/sonar-education-plugin/src/main/java/org/sonar/education/sensors/EducationRuleSensor.java)
5. Add the plugin as a dependency in build.gradle and register it in the root settings (build.gradle)

Add Issue Filtering or Post-Processing

1. Create an IssueFilter class in plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/extensions/ (plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/extensions/XooIssueFilter.java)
2. Implement the accept() method to suppress, modify, or annotate issues based on custom logic (plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/extensions/XooIssueFilter.java)
3. Register the filter in the plugin's addExtensions() method (plugins/sonar-xoo-plugin/src/main/java/org/sonar/xoo/XooPlugin.java)

• Gradle & Java 21 — Multi-module build system supporting plugin architecture; Java 21 provides modern language features and performance
• Plugin-based architecture — Allows extensibility without modifying core; enables language-specific and custom rule implementations
• Sensor pattern — Decouples analysis logic from core engine; each sensor can independently report metrics, issues, and architectural violations
• Quality Profiles — Provides configuration layer to activate/deactivate rules without code changes; enables different organizations to enforce different standards
• Issue Filters & Post-Jobs — Allows post-processing and suppression of issues based on context; supports integration with external systems

• Test language (Xoo) included in main repo

  • Why: Simplifies testing and demonstration of the plugin framework without external dependencies
  • Consequence: Increases repo size and coupling; makes it harder to version independently

• Separate Education plugin for examples

  • Why: Isolates educational/reference implementations from core test language
  • Consequence: Duplication of

JDK 21+ enforcement: Build fails immediately if Java < 21 (strict version check in build.gradle; no fallback). eddsa exclusion: net.i2p.crypto:eddsa is globally excluded—do not add it as a transitive dependency. BOM generation: Enabled only on main/release branches or with -Dbom flag; local dev builds skip it (see gradle.properties for buildNumber logic). Plugin registration: Plugins must implement specific SonarSource interfaces (RulesDefinition, LanguageDefinition, Sensor); interfaces come from sonar-plugin-api (not visible in file list; check Maven Central for dependency version). Artifactory setup: build.gradle applies jfrog.artifactory plugin; CI likely requires ARTIFACTORY_USER/PASSWORD environment variables for publishing.

• Quality Gate — Central enforcement mechanism in SonarQube—blocks deployments if code metrics (coverage, bugs, security) fail thresholds. Understanding Quality Gate logic is essential for any modification to issue evaluation or severity rules.
• Plugin Architecture (Microkernel Pattern) — SonarQube extends via plugins (see sonar-education-plugin); each plugin registers Rules, Languages, and Sensors. Learning this pattern is mandatory for any feature addition beyond core.
• Abstract Syntax Tree (AST) Traversal — Sensors analyze code by traversing ASTs; sonar-education-plugin sensors likely visit syntax nodes to detect issues. Core skill for writing effective custom rules.
• Protobuf Serialization — Build uses com.google.protobuf plugin for code generation; .proto files likely define issue/metric interchange formats between server and plugins. Affects inter-process communication.
• Bill of Materials (SBOM / CycloneDX) — build.gradle includes cyclonedxBom plugin for supply-chain transparency; SonarQube publishes dependency inventory. Important for security-conscious deployments.
• Gradle Multi-Module Build — SonarQube is a multi-module Gradle project (plugins/ subdirectory, buildSrc/ plugins); understanding inter-module dependencies and task ordering is essential for local builds.
• Shadow/Uber JAR Packaging — build.gradle applies com.gradleup.shadow plugin; likely creates fat JARs for plugins to avoid classpath conflicts. Critical for understanding deployment artifacts.

• SonarSource/sonarqube-webapp — Official frontend for SonarQube server; handles Quality Gate UI, issue dashboards, and configuration—run alongside this backend
• SonarSource/sonar-java — Official Java language analyzer plugin; shows best practices for extending SonarQube with language-specific rules and AST visitors
• SonarSource/sonar-python — Official Python analyzer; same architecture as sonar-java, useful reference for understanding multi-language plugin pattern
• nexB/scancode-toolkit — Complementary open-source license/component scanner; often paired with SonarQube for supply-chain security (supply-chain focus visible in BOM generation)
• aquasecurity/trivy — Lightweight vulnerability scanner often integrated into SonarQube pipelines for container/OS-level scanning alongside code quality gates

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for EducationPlugin sensors

The sonar-education-plugin has multiple sensor implementations (EducationPrinciplesSensor, EducationWith2LinkedCodeSnippetsSensor, etc.) with unit tests, but there are no integration tests validating how these sensors work together with the plugin's BuiltInQualityProfile and RulesDefinition. This would ensure the education rules actually execute correctly in a real SonarQube analysis context and catch regressions early.

• [ ] Create plugins/sonar-education-plugin/src/test/java/org/sonar/education/EducationPluginIntegrationTest.java
• [ ] Use SonarQubeRule or similar test harness to validate full plugin lifecycle
• [ ] Test that all rule definitions from EducationRulesDefinition are properly registered and executable
• [ ] Verify sensor data flows correctly through the EducationPrinciplesSensor and context-based sensors
• [ ] Add integration tests for the HTML code snippet resources (2codeSnippets.html, 4codeSnippets.html, etc.) rendering in rules

Add BlackBoxTest coverage for the education plugin build and packaging

The buildSrc/src/main/groovy/org.sonar.build/BlackBoxTest.groovy class exists but there's no evidence of blackbox tests being run for the sonar-education-plugin. This plugin should have blackbox tests validating that the JAR is properly built, manifests are correct, and the plugin can be loaded into a real SonarQube instance without errors.

• [ ] Create plugins/sonar-education-plugin/src/test/java/org/sonar/education/BlackBoxTestEducationPlugin.java extending BlackBoxTest
• [ ] Configure build.gradle in sonar-education-plugin to execute blackbox tests post-build
• [ ] Validate plugin JAR metadata and manifest contents
• [ ] Test plugin installation into a test SonarQube instance and verify all extensions are discoverable
• [ ] Add validation that the education language and quality profile are properly registered on startup

Add missing test for EducationWithDetectedContextSensor

In plugins/sonar-education-plugin/src/test/java/org/sonar/education/sensors/, there is no test file for EducationWithDetectedContextSensor.java (which exists in src/main). This is an asymmetry that leaves a sensor untested, violating the pattern established by other sensors in the plugin.

• [ ] Create plugins/sonar-education-plugin/src/test/java/org/sonar/education/sensors/EducationWithDetectedContextSensorTest.java
• [ ] Follow the same test structure as EducationWithContextsSensorTest.java
• [ ] Test context detection logic and verify correct issue reporting
• [ ] Validate that detected contexts are properly identified and linked to issues
• [ ] Ensure coverage of edge cases (no context detected, multiple contexts, etc.)

• Add unit tests for EducationWithDetectedContextSensor.java—sensor file exists but test coverage unclear from file list. Create src/test/java/.../EducationWithDetectedContextSensorTest.java following existing test patterns.: Improves test coverage for core plugin feature; helps learner understand sensor lifecycle and mock testing patterns
• Document the sensor architecture in docs/contributing.md—file exists but likely lacks sensor-specific examples. Add section explaining how to extend AbstractPhpSensor-like base classes, with code snippet from EducationPrinciplesSensor.java.: Removes friction for future plugin contributors; tests contributing.md completeness against real examples
• Add GitHub Actions workflow step to run ./gradlew :plugins:sonar-education-plugin:build in isolation and publish plugin artifact to Maven Local. Current build.yml likely builds everything; isolated plugin CI accelerates feedback for plugin-only PRs.: Improves developer experience for plugin contributors; demonstrates GitHub Actions matrix testing against real build matrix

The SonarQube repository has moderate security concerns. The most critical issue is an exposed authentication token in the README.md file that requires immediate remediation. Secondary concerns include excluded cryptographic dependencies, incomplete build configuration, and the presence of compiled JAR files in version control. The plugin architecture and web application security headers also warrant review. Overall, while the project follows some good practices (dependency management, Java version enforcement), the exposed credentials and dependency management issues lower the security posture.

• High · Hardcoded SonarQube Token in README — README.md - AI Code Assurance badge URL. A SonarQube authentication token is exposed in the README.md file within the AI Code Assurance badge URL. The token 'sqb_c0e2fa9ac4ef89f9a8403c6ba235e108ceb1dce1' is publicly visible in the repository. Fix: Immediately rotate this token. Replace the hardcoded token with a masked or placeholder value. Use GitHub Secrets for sensitive credentials and reference them in CI/CD pipelines instead of embedding them in repository files.
• High · Excluded Security Dependency (EdDSA) — build.gradle - configurations.all exclusion. The build configuration globally excludes the 'net.i2p.crypto:eddsa' dependency across all projects. While this may be intentional, excluding cryptographic libraries can indicate potential security misconfigurations or unaddressed vulnerabilities. Fix: Review the rationale for excluding EdDSA. If excluded to avoid conflicts, ensure the replacement provides equivalent security. Document this decision and regularly audit for security implications.
• Medium · Incomplete Version Management in Gradle — build.gradle - version assignment section. The build.gradle file has incomplete version assignment logic with a truncated line 've' that appears to be cut off. This could indicate corrupted or incomplete build configuration that may bypass version validation. Fix: Complete and review the version assignment logic. Ensure all version-related code is properly formatted and tested. Verify that version validation is consistently applied.
• Medium · Gradle Wrapper JAR in Repository — gradle/wrapper/gradle-wrapper.jar. The gradle-wrapper.jar file is committed to the repository. While Gradle wrapper is commonly used, JAR files in repositories can be vectors for supply chain attacks if the wrapper is compromised. Fix: Verify the integrity of gradle-wrapper.jar by checking its checksum against official Gradle distributions. Consider implementing wrapper validation in CI/CD pipelines using Gradle's wrapper validation mechanism.
• Low · Missing Security Headers Configuration — Project configuration files. No evidence of security header configuration (CSP, X-Frame-Options, X-Content-Type-Options, etc.) in visible configuration files for the web application. Fix: Implement comprehensive security headers in the SonarQube web application configuration. Add Content Security Policy, X-Frame-Options, X-Content-Type-Options, and other relevant security headers.
• Low · Plugin System Without Visible Code Validation — plugins/ directory. The codebase includes extensible plugin systems (sonar-education-plugin, sonar-xoo-plugin) without visible code validation or sandbox mechanisms in the provided structure. Fix: Implement strict code validation and sandboxing for dynamically loaded plugins. Ensure plugins are signed and verified before execution. Limit plugin capabilities to necessary APIs.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.