跳到正文
cccskills
免费在 GitHub 公开

sonarqube-rules

Configures and runs SonarQube / SonarCloud - multi-language SAST + Quality Gate platform with built-in Sonar Way rule profiles + custom rule plugins; integrates `sonar-scanner` with `sonar-project.properties` config; supports Quality Gate definitions including new-code-period blocking, branch + PR analysis, and per-issue suppression via `// NOSONAR` comment or `@SuppressWarnings("squid:RULE_ID")` annotation. Use when the user runs SonarQube Community / Developer / Enterprise edition or SonarCloud, or needs a multi-language SAST + code-quality platform with persistent issue tracking.

中文简介正在准备中。当前显示原文说明。

testland/qa星标 13(GitHub 13 + cccskills 0)

实测评分 未实测

查看安装方法

包含的文件(2)

  • SKILL.md7.8 KB
  • .tessl-plugin/plugin.json722 B

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

sonarqube-rules

Overview

Per github.com/SonarSource/sonarqube:

"SonarQube provides the capability to not only show the health of an application but also to highlight issues newly introduced."

The platform's distinguishing features vs Semgrep / CodeQL:

  • Quality Gate - pass/fail decision based on configurable threshold conditions (coverage on new code, duplication, security hotspots reviewed, maintainability rating, etc.).
  • New-code-period - issues are categorized as "new code" vs "overall code"; gates focus on new-code metrics so legacy debt doesn't block deploys.
  • Persistent issue tracking - server-side storage of issues across scans; status workflow (open / confirmed / resolved / false positive / won't fix).
  • Cross-language coverage - 30+ languages with one tool + unified UI.

When to use

  • Existing SonarQube deployment (Community / Developer / Enterprise / SonarCloud).
  • The team needs persistent issue tracking + Quality Gate workflow.
  • Multi-language coverage in one platform is a requirement.
  • New-code-period gating fits the team's deploy cadence.

For new projects without a SonarQube investment, evaluate semgrep-rules (lower friction; no server) first.

Step 1 - Install (server side)

Per docs.sonarsource.com/sonarqube-server:

Docker (most common for evaluation):

docker run -d --name sonarqube \
  -p 9000:9000 \
  sonarqube:lts-community

For production, consult sq-docs for Postgres + JVM sizing + reverse-proxy configuration. Default admin: admin / admin (change immediately).

Step 2 - sonar-scanner CLI

Download from docs.sonarsource.com/sonarqube-server → "Analysis scanners". Place on PATH.

sonar-scanner \
  -Dsonar.projectKey=my-project \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.token=$SONAR_TOKEN

For Maven / Gradle / .NET, use the language-native scanner plugin (mvn sonar:sonar / ./gradlew sonar / dotnet sonarscanner).

Step 3 - sonar-project.properties config

Project-root file replaces -D flags:

# sonar-project.properties
sonar.projectKey=my-project
sonar.projectName=My Project
sonar.sources=src
sonar.tests=tests
sonar.exclusions=**/*.spec.ts,**/generated/**
sonar.sourceEncoding=UTF-8

# Coverage from external tool (Jest, JaCoCo, etc.)
sonar.javascript.lcov.reportPaths=coverage/lcov.info

# New-code-period (analysis scope)
sonar.newCode.referenceBranch=main

# Quality Gate (referenced by ID; created via UI/API)
sonar.qualitygate.wait=true

sonar.qualitygate.wait=true makes the scanner block until the gate decision is computed - critical for CI gating.

Step 4 - Quality Gate concept

The default "Sonar Way" gate enforces (consult your SonarQube UI at Quality Gates → Sonar Way for current conditions):

  • Coverage on New Code ≥ X%
  • Duplicated Lines on New Code ≤ Y%
  • Maintainability Rating on New Code = A
  • Reliability Rating on New Code = A
  • Security Rating on New Code = A
  • Security Hotspots on New Code reviewed = 100%

Custom gates can be defined via UI or REST API (/api/qualitygates/create).

Step 5 - Branch + PR analysis

For PR analysis (Developer edition+):

sonar-scanner \
  -Dsonar.pullrequest.key=$PR_NUMBER \
  -Dsonar.pullrequest.branch=$PR_BRANCH \
  -Dsonar.pullrequest.base=main

PR results post as comments to GitHub / GitLab / Bitbucket per the integration setup in SonarQube admin.

Step 6 - False-positive triage (MANDATORY)

Three suppression layers in priority order:

MechanismExampleWhen to use
Per-line NOSONARint x = 0; // NOSONAR justification textSingle-line exception with inline reason
Annotation@SuppressWarnings("squid:S106")Java/Kotlin per-block exception
Server-side mark-as-FPUI: Issues → Resolve as False PositivePersistent across scans; auditable
Server-side mark-as-Won't FixUI: Issues → Resolve as Won't FixAcknowledged risk; not a defect

Justification template (mandatory in code):

// NOSONAR squid:S106 - Reason: required for CLI tool stdout output
// Reviewer: alice@example.com (2026-05-15)
// Expires: 2026-12-15
System.out.println(message);

Server-side resolution requires a comment per SonarQube workflow config - make it mandatory in admin settings (Administration → Configuration → Issues → Comment required to set status).

Cadence: Issues → False Positive filter periodically; review for expiration. Server-side resolutions are persistent and auditable - the audit trail is the value over Semgrep's per-comment approach.

Step 7 - CI integration

jobs:
  sonarqube:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with: { fetch-depth: 0 }   # full history needed for new-code-period
      - uses: SonarSource/sonarqube-scan-action@v5
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
      - uses: SonarSource/sonarqube-quality-gate-action@v1
        timeout-minutes: 5
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

fetch-depth: 0 is critical - without full git history, new-code-period detection is broken.

Step 8 - REST API integration

For automation / dashboards:

EndpointUse
GET /api/issues/search?projectKeys=...Issue list with filters
GET /api/qualitygates/project_statusCurrent gate verdict
POST /api/issues/do_transitionMark FP / Won't Fix
GET /api/measures/component_treePer-file metrics

API token via User → My Account → Security → Generate Tokens.

Anti-patterns

Anti-patternWhy it failsFix
fetch-depth: 1 in CINew-code-period broken; gates produce wrong decisionsAlways fetch-depth: 0 (Step 7)
Skip sonar.qualitygate.waitCI exits before gate evaluates; missed regressionssonar.qualitygate.wait=true (Step 3)
NOSONAR without justificationServer-side audit trail emptyRequired template (Step 6)
Custom Quality Gate without team buy-inGate fails on PRs no one understandsDocument gate definition; reference in PR template
Mass-resolve as FP without reviewBackdoor for skipping security findingsRequire comment + reviewer attribution (Step 6)

Limitations

  • SonarQube server requires hosting + maintenance; SonarCloud is the SaaS alternative.
  • Branch + PR analysis are Developer-edition+ features - Community edition only supports main branch.
  • Some language-specific deep-rule features require Developer or Enterprise edition.
  • New-code-period requires accurate git history; shallow clones break it.
  • License changed from LGPL to SSPL in 2024 - verify license compatibility for commercial use.

References

  • sq-gh - repository
  • sq-docs - official SonarQube documentation root
  • docs.sonarsource.com/sonarqube-server/latest/user-guide/quality-gates - Quality Gates user guide
  • docs.sonarsource.com/sonarqube-server/latest/user-guide/issues - Issue workflow + transitions
  • semgrep-rules, codeql-queries, language-native-sast - sister scanners

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Builds a CI gate that fails the build on **new** WCAG / a11y violations introduced by a PR while grandfathering pre-existing violations on a per-rule / per-page baseline. Aggregates verdicts from axe-core / pa11y / Lighthouse a11y / WAVE / IBM Equal Access scans. Use when a project has accumulated a11y debt and a strict "zero violations" gate would block every PR - the ratchet pattern lets the team ship while preventing regressions.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

Workflow skill that builds an A/B-test validity checklist from an experiment proposal, walking the canonical design-correctness gates - pre-registered OEC/power/guardrails, randomization unit + SRM check, assignment integrity, telemetry, peeking discipline, novelty/primacy, post-experiment SRM re-check - into a per-experiment checklist + sign-off form. Use when launching, auditing, or governing an experiment. For pitfall mechanics (guardrails, peeking) see experiment-results-interpreter's references; to read an already-valid result use experiment-results-interpreter; for per-SDK harness tests use experiment-sdk-testing - this gates DESIGN, not SDK code.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

The single install-flow skill: the reference contract for the PWA install flow (installability gate fields, `beforeinstallprompt` handshake, per-platform paths - Android WebAPK / iOS Share menu / Firefox no-op - and the `display-mode` post-install signal, in references/install-flow-reference.md) plus the build-an-X workflow that emits the Add-to-Home-Screen suite. Walks the four-stage timeline, emitting one test per gate cell per [web.dev/articles/install-criteria][install-criteria], the deferred-prompt → `prompt()` → `userChoice` chain per [web.dev/articles/customize-install][customize-install], the iOS Safari manual-metadata branch (`apple-touch-icon`) per [web.dev/learn/pwa/installation][learn-pwa], and the post-install `(display-mode: standalone)` MQ assertion. Output: a Playwright spec with per-stage cells plus a coverage matrix. Use when a PWA's manifest, icons, or install handler change, when install conversion drops at an unknown stage, or when triaging a flaky install assertion.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

Build-an-X workflow that uses an LLM to map existing tests to spec sections - given a spec doc + the test suite, the LLM identifies which tests cover which sections, surfaces uncovered sections (gap), and recommends specific tests to add. Output is a coverage matrix per spec ID. Scope is mapping tests that already exist and naming the gaps, not authoring tests for new acceptance criteria. Use when a spec doc and a test suite both exist but nobody can say which requirements are actually covered - before a release sign-off, an audit, or a decision about where to spend the next round of test effort.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

Generates tests from natural-language specs (acceptance criteria, user stories, requirements) using an LLM, with confidence scoring per test case (LLM self-assessment plus heuristics: assertion quality, naming, completeness), batching uncertain cases for human review, and integration with the team's existing test framework. Use when the user asks to generate unit tests from acceptance criteria, convert user stories to test cases, automate test creation from requirements, or augment a spec-driven test suite with AI-generated stubs that are then curated before merge.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to the sunset ExtentReports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.

中文简介正在准备中。当前显示原文说明。

testland/qa132026年10月20日 更新

查看 testland 的全部技能

报告此技能的问题