Kopplar in SonarQube-analys mot den självhostade instansen (sonar.siax.io) för c0py.
Ny sonar-project.properties (projectKey=c0py, källor under apps/*/src och packages/*/src).
Ny sonar-job i .gitea/workflows/ci.yml som kör sonar-scanner i en container via docker create/cp/start (samma mönster som verifierat på siax-io #110), men bara vid push till main — SonarQube Community Build har inget separat PR-analysläge, så en analys från en PR-branch skulle skriva över kvalitetshistoriken.
Repot hade ingen tidigare SonarCloud- eller analysuppkoppling — detta ersätter alltså inget, det är helt ny funktionalitet.
Eftersom jobbet bara kör på push till main dyker det inte upp som en check på denna PR (det körs som "skipped" på pull_request-eventet per design) — det blir grönt först efter merge, förutsatt att SONAR_TOKEN-secreten finns på repot.
Obs:SONAR_TOKEN-secreten kunde inte sättas av mig i denna körning (blockerad av Claude Codes auto-mode-klassificerare för secret-store-writes) — den behöver läggas till manuellt eller av en session med den behörigheten innan sonar-jobbet kan lyckas efter merge: värdet finns i Infisical (prod-miljön, nyckel SONAR_TOKEN).
Kopplar in SonarQube-analys mot den självhostade instansen (sonar.siax.io) för c0py.
- Ny `sonar-project.properties` (projectKey=c0py, källor under `apps/*/src` och `packages/*/src`).
- Ny `sonar`-job i `.gitea/workflows/ci.yml` som kör `sonar-scanner` i en container via docker create/cp/start (samma mönster som verifierat på siax-io #110), men **bara vid push till main** — SonarQube Community Build har inget separat PR-analysläge, så en analys från en PR-branch skulle skriva över kvalitetshistoriken.
- Repot hade ingen tidigare SonarCloud- eller analysuppkoppling — detta ersätter alltså inget, det är helt ny funktionalitet.
Eftersom jobbet bara kör på push till main dyker det inte upp som en check på denna PR (det körs som "skipped" på pull_request-eventet per design) — det blir grönt först efter merge, förutsatt att `SONAR_TOKEN`-secreten finns på repot.
**Obs:** `SONAR_TOKEN`-secreten kunde inte sättas av mig i denna körning (blockerad av Claude Codes auto-mode-klassificerare för secret-store-writes) — den behöver läggas till manuellt eller av en session med den behörigheten innan sonar-jobbet kan lyckas efter merge: värdet finns i Infisical (`prod`-miljön, nyckel `SONAR_TOKEN`).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Repo: c0py. Lägger till sonar-project.properties (projectKey=c0py) och
en ny sonar-job i .gitea/workflows/ci.yml som kör sonar-scanner mot
sonar.siax.io vid push till main (Community Build saknar PR-analysläge).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
admin
merged commit 67e0b5126f into main2026-09-28 10:03:37 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Kopplar in SonarQube-analys mot den självhostade instansen (sonar.siax.io) för c0py.
sonar-project.properties(projectKey=c0py, källor underapps/*/srcochpackages/*/src).sonar-job i.gitea/workflows/ci.ymlsom körsonar-scanneri en container via docker create/cp/start (samma mönster som verifierat på siax-io #110), men bara vid push till main — SonarQube Community Build har inget separat PR-analysläge, så en analys från en PR-branch skulle skriva över kvalitetshistoriken.Eftersom jobbet bara kör på push till main dyker det inte upp som en check på denna PR (det körs som "skipped" på pull_request-eventet per design) — det blir grönt först efter merge, förutsatt att
SONAR_TOKEN-secreten finns på repot.Obs:
SONAR_TOKEN-secreten kunde inte sättas av mig i denna körning (blockerad av Claude Codes auto-mode-klassificerare för secret-store-writes) — den behöver läggas till manuellt eller av en session med den behörigheten innan sonar-jobbet kan lyckas efter merge: värdet finns i Infisical (prod-miljön, nyckelSONAR_TOKEN).🤖 Generated with Claude Code