spikerj/spikersoft-issues
1
0 Fork 0
Code Issues 23 Pull Requests Actions Packages Projects Releases Wiki Activity

SonarQube is Enterprise — enable branch/PR analysis across repo scans #991

New Issue
Closed
opened 2026-08-07 00:01:24 +00:00 by spikerj · 1 comment
spikerj commented 2026-08-07 00:01:24 +00:00
Owner
Copy link
Copy source

Discovered while wiring the mobile scans (#990): the server is Enterprise Edition, but the whole fleet treats it as Community:

  • spikersoft-backend/.gitea/workflows/sonar-scan.yml explicitly says "The server is Community Edition (no branch/PR analysis)" and disabled the PR trigger for that reason after #632 (a PR-event scan without branch params replaced the main-baseline analysis).
  • The angular, backend, and the new mobile scan workflows (ios #9 / android #7) all run on default-branch pushes only.

With Enterprise, PR-event scans can pass sonar.pullrequest.key / sonar.pullrequest.branch / sonar.pullrequest.base (Gitea isn't auto-detected by the scan action, so these need to be set explicitly from the workflow context, e.g. ${{ gitea.event.pull_request.number }}) and SonarQube creates a proper short-lived PR analysis — new-code issues visible per PR, main baseline untouched, no #632 hazard.

Scope:

  1. Add a PR-triggered job (or extend the existing workflow) per repo passing the three pullrequest params; keep the main-push job as-is for the baseline.
  2. Fix the stale Community-Edition comments in backend + mobile workflows.
  3. Optional: quality-gate status check on PRs (non-blocking at first, same stance as today).
  4. Note: PR decoration (comments in the PR UI) has no native Gitea integration — the analyses live in the SonarQube UI under the project's pull-request tab.
Discovered while wiring the mobile scans (#990): the server is **Enterprise Edition**, but the whole fleet treats it as Community: - `spikersoft-backend/.gitea/workflows/sonar-scan.yml` explicitly says "The server is Community Edition (no branch/PR analysis)" and disabled the PR trigger for that reason after #632 (a PR-event scan without branch params replaced the main-baseline analysis). - The angular, backend, and the new mobile scan workflows (ios #9 / android #7) all run on default-branch pushes only. With Enterprise, PR-event scans can pass `sonar.pullrequest.key` / `sonar.pullrequest.branch` / `sonar.pullrequest.base` (Gitea isn't auto-detected by the scan action, so these need to be set explicitly from the workflow context, e.g. `${{ gitea.event.pull_request.number }}`) and SonarQube creates a proper short-lived PR analysis — new-code issues visible per PR, main baseline untouched, no #632 hazard. Scope: 1. Add a PR-triggered job (or extend the existing workflow) per repo passing the three pullrequest params; keep the main-push job as-is for the baseline. 2. Fix the stale Community-Edition comments in backend + mobile workflows. 3. Optional: quality-gate status check on PRs (non-blocking at first, same stance as today). 4. Note: PR *decoration* (comments in the PR UI) has no native Gitea integration — the analyses live in the SonarQube UI under the project's pull-request tab.
spikerj commented 2026-08-07 13:50:09 +00:00
Author
Owner
Copy link
Copy source

Verified complete 2026-08-07 — closing.

  • Code: PR-event Sonar analysis with explicit sonar.pullrequest.* params is merged on the default branch of all four scanned repos:
    • spikersoft-angular@8e5a4048 — .gitea/workflows/sonarqube-scan.yml:5 (pull_request trigger) + :76 (key/branch/base).
    • spikersoft-backend@98102023 — .gitea/workflows/sonar-scan.yml:19-20 PR trigger; the params are deliberately not passed here because highbyte/sonarscan-dotnet injects them itself and the .NET scanner aborts on duplicates — documented inline at :12-15.
    • spikersoft-ios@6926525 — .gitea/workflows/sonar-scan.yml:15-16 + :48.
    • spikersoft-android@fbe33d3 — .gitea/workflows/sonar-scan.yml:12-13 + :44.
    • Scope item 2 done: grep -rn "Community Edition" .gitea/ across all four repos returns zero hits; each header now names the Enterprise/#632 rationale.
  • Live (SonarQube API, 2026-08-07): api/navigation/global → edition datacenter, v2026.2 (build 121184) — branch/PR analysis licensed. api/project_pull_requests/list shows real short-lived PR analyses on every project, including post-#991 PRs analysed today:
    • api.spikersoft.com → PR 528 (feat/sonar-pr-analysis, gate OK, 2026-08-07T04:30Z)
    • learn.spikersoft.com → PRs 623, 625, 626 (latest 2026-08-07T11:55Z)
    • spikersoft-ios → PRs 11, 12, 13, 14, 15 (latest 2026-08-07T13:36Z)
    • spikersoft-android → PRs 9, 12, 13, 14 (latest 2026-08-07T13:40Z)
      Each carries base: master/main and a qualityGateStatus, i.e. the analyses are typed as pull requests and the main baseline is untouched — the #632 hazard did not recur.
  • Shipped by: backend PR #528, angular PR #623, ios PR #11, android PR #9.

Scope item 3 (a quality-gate status check on PRs) was flagged optional in the body and is not implemented; item 4 was a note, not work. Not split, because the per-repo workflow edits are already merged everywhere.

Not migrated: nothing left to do.

— Opus 5 Agent

Verified complete 2026-08-07 — closing. - **Code:** PR-event Sonar analysis with explicit `sonar.pullrequest.*` params is merged on the default branch of all four scanned repos: - `spikersoft-angular@8e5a4048` — `.gitea/workflows/sonarqube-scan.yml:5` (`pull_request` trigger) + `:76` (key/branch/base). - `spikersoft-backend@98102023` — `.gitea/workflows/sonar-scan.yml:19-20` PR trigger; the params are deliberately **not** passed here because `highbyte/sonarscan-dotnet` injects them itself and the .NET scanner aborts on duplicates — documented inline at `:12-15`. - `spikersoft-ios@6926525` — `.gitea/workflows/sonar-scan.yml:15-16` + `:48`. - `spikersoft-android@fbe33d3` — `.gitea/workflows/sonar-scan.yml:12-13` + `:44`. - Scope item 2 done: `grep -rn "Community Edition" .gitea/` across all four repos returns **zero** hits; each header now names the Enterprise/#632 rationale. - **Live (SonarQube API, 2026-08-07):** `api/navigation/global` → edition **`datacenter`**, v2026.2 (build 121184) — branch/PR analysis licensed. `api/project_pull_requests/list` shows real short-lived PR analyses on every project, including post-#991 PRs analysed today: - `api.spikersoft.com` → PR 528 (`feat/sonar-pr-analysis`, gate OK, 2026-08-07T04:30Z) - `learn.spikersoft.com` → PRs 623, 625, 626 (latest 2026-08-07T11:55Z) - `spikersoft-ios` → PRs 11, 12, 13, 14, 15 (latest 2026-08-07T13:36Z) - `spikersoft-android` → PRs 9, 12, 13, 14 (latest 2026-08-07T13:40Z) Each carries `base: master`/`main` and a `qualityGateStatus`, i.e. the analyses are typed as pull requests and the main baseline is untouched — the #632 hazard did not recur. - **Shipped by:** backend PR #528, angular PR #623, ios PR #11, android PR #9. Scope item 3 (a quality-gate status check on PRs) was flagged optional in the body and is not implemented; item 4 was a note, not work. Not split, because the per-repo workflow edits are already merged everywhere. Not migrated: nothing left to do. — Opus 5 Agent
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
agentic
Actionable surfaced by the agentic architecture & security review
 bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 epic
Cross-repo epic — children live in per-repo trackers
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 sonarqube
Code quality issue surfaced by SonarQube (bug / code smell)
 wontfix
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
spikerj (Joseph Spiker)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#991