SonarQube-Analyse aufnehmen, als geteilten Baustein in pipelines #71

New Issue

2026-10-02T01:19:59+02:00

jlab-bot commented

2026-10-02 01:19:59 +02:00

Eine SonarQube-Analyse aufnehmen, als geteilter Baustein in workflow-util/pipelines, aufgerufen aus helm-charts.

Grundlage ist der vom Betreuer vorgegebene Schnipsel; dieser Text ist der freigegebene Plan.

Verifizierte Fakten

Die Analysatoren passen zu diesem Repository. Aus der Sprachliste von SonarQube geprüft: Shell wird unterstützt (ich hatte das Gegenteil vermutet), ebenso GitHub Actions, Kubernetes/Helm, YAML, JSON und Secrets. Was hier liegt:

Was	Analysator
5 Shell-Skripte unter `ci/` — die ganze CI-Logik	Shell
~30 Workflow-Dateien	GitHub Actions
238 YAML und 26 Helm-Templates	Kubernetes/Helm, YAML
26 `values.schema.json`	JSON
der ganze Baum	Secrets

Der Secrets-Analysator ist der wertvollste Teil: Die Prämisse dieses Repositories ist, dass niemals ein Zugangsdatum darin landet, und bisher prüft das nichts.

Die Scan-Action ist eine JavaScript-Action, keine Docker-Action. SonarSource/sonarqube-scan-action@v8.1.0 deklariert runs: using: node24. Folgen:

runs-on: ubuntu-latest genügt — der Docker-Socket, den nur ubuntu-docker hat, ist nicht nötig.
Sie lädt den Sonar-Scanner-CLI zur Laufzeit von binaries.sonarsource.com und prüft dessen GPG-Signatur. Das ist ein Download in der Größenordnung mehrerer zehn MB über das Netz des Runners.
Sie verlangt node24 im Runner-Image. Ob das vorhanden ist, ist nicht geprüft.

SonarQube läuft im eigenen Cluster (jlab-sonar-db in cluster-config), und SONAR_HOST_URL ist auf der Instanz bereits als Variable gesetzt — nicht als Secret, anders als im Schnipsel.

Entschieden

Als Baustein in workflow-util/pipelines. Der Workflow ist für jedes Repository identisch; das Projektspezifische steht in sonar-project.properties im jeweiligen Repo, nicht im Workflow. Damit ist die Wiederverwendung fast kostenlos, und cluster-config sowie die suer-Projekte können ihn sofort mitbenutzen.
Auslöser: nur Push auf main. Lauffähig auf jeder Edition — die Community Build analysiert ausschließlich den Hauptzweig. Folge, die benannt gehört: Ein Befund erscheint nach dem Merge. Sonar ist hier eine Beobachtung des Zustands, kein Torwächter.
Kein Quality-Gate-Schritt. Bei einem Auslöser nach dem Merge gibt es nichts zu blockieren; ein rotes Gate färbte nur main rot, und solche Dauerzustände lernt man zu ignorieren. Sinnvoll erst, wenn PR-Analyse möglich ist oder ein Deployment daran hängt.
Kein Ausschluss. Der ganze Baum, Helm-Templates eingeschlossen. Der erste Lauf zeigt damit auch, was der Helm-Analysator mit Dateien macht, die wegen {{ }} kein gültiges YAML sind — eine Information, die wir sonst nie bekommen.

Aufbau

In pipelines: .gitea/workflows/sonar-analysis.yml, on: workflow_call. Checkout mit fetch-depth: 0 (ohne das wird die Zuordnung von Befunden zu Änderungen unbrauchbar), danach die Scan-Action. Beide Actions auf SHA gepinnt, wie im Schnipsel — das deckt sich mit der dortigen Hausregel und mit deren offenem Issue #5, das einen wandernden @master-Verweis beanstandet.

SONAR_TOKEN aus dem Secret des Aufrufers, SONAR_HOST_URL aus vars.
Je ein Wächter für beide, der das Fehlen laut benennt — ein leeres SONAR_HOST_URL ergäbe sonst einen Fehler gegen eine Adresse, die niemand sieht; genau dieses Muster haben wir beim Publish-Baustein schon gebraucht.
Eingaben nur als string, auch wenn eine inhaltlich ein Schalter ist: Auf dieser Gitea-Fassung kommen boolesche workflow_call-Eingaben nachweislich nicht an (dortiges Issue #4, gemessen an 1.27.0, bei grünem Lauf). Vorgesehen sind args und project-base-dir, beide optional.
Neuer Tag v4, repository-weit nach der dortigen Konvention. Dass die Nummer den Zustand des Repositories bezeichnet und nicht die Version einer Datei, steht dort seit v3 dokumentiert.

In helm-charts: .github/workflows/sonar.yml, on: push auf main, Aufruf an @v4 mit secrets: inherit. Dazu sonar-project.properties mit Projektschlüssel — Vorschlag jlab-cluster_helm-charts, weil die Instanz zwei Eigentümer bedient und ein nackter helm-charts beim zweiten kollidieren würde. Falls der Betreuer einen anderen Schlüssel will, wird der genommen.

Voraussetzungen

Name	Art	Zustand
`SONAR_HOST_URL`	Variable	gesetzt
`SONAR_TOKEN`	Secret	offen — muss im aufrufenden Repository oder auf Organisationsebene vorliegen

Das Token braucht in SonarQube das Recht, Analysen auszuführen; soll das Projekt beim ersten Lauf selbst entstehen, zusätzlich das Recht zum Anlegen.

Was gemessen werden muss, nicht angenommen

Ist node24 im Runner-Image vorhanden? Die Action verlangt es. Fehlt es, scheitert sie, und zwar mit einer Meldung über die Action, nicht über das Image.
Kommt der Scanner-Download durch? Das ist die wahrscheinlichste Stelle für den ersten Fehlschlag: In der README dieses Repositories steht gemessen, dass auf diesem Runner einmal eine 17-MB-Datei nicht durchkam, weil die Docker-Brücke mit MTU 1500 gegen ein Pod-Netz mit 1450 lief — kleine Antworten passten in ein Paket, die große nicht. Das wurde auf der Knoten-Seite behoben; der Scanner-CLI ist deutlich größer als 17 MB.
Kommt vars.SONAR_HOST_URL in einem aus einem fremden Repository aufgerufenen Workflow an? Dasselbe Offene wie bei OP_CONNECT_HOST im Publish-Baustein — dort ebenfalls noch unbelegt.
Was der erste Lauf tatsächlich meldet, insbesondere aus den Helm-Templates. Das Ergebnis gehört in den PR-Text, weil es entscheidet, ob Ausschlüsse nachträglich nötig sind.

Dokumentation

In pipelines: README-Abschnitt in der dortigen Struktur (Zweck, Eingaben-Tabelle, Aufrufbeispiel, Voraussetzungen) plus Wiki-Seite in der Reihe der Bausteine, und ein Eintrag auf Gemessenes-Verhalten, sobald zu node24 oder dem Download etwas gemessen ist.

In helm-charts: README im CI-Abschnitt und die Wiki-Seite CI-CD — was analysiert wird, was nicht blockiert, und dass ein Befund erst nach dem Merge erscheint.

Eine SonarQube-Analyse aufnehmen, als **geteilter Baustein** in `workflow-util/pipelines`, aufgerufen aus `helm-charts`. Grundlage ist der vom Betreuer vorgegebene Schnipsel; dieser Text ist der freigegebene Plan. ## Verifizierte Fakten **Die Analysatoren passen zu diesem Repository.** Aus der Sprachliste von SonarQube geprüft: **Shell** wird unterstützt (ich hatte das Gegenteil vermutet), ebenso **GitHub Actions**, **Kubernetes/Helm**, **YAML**, **JSON** und **Secrets**. Was hier liegt: | Was | Analysator | |---|---| | 5 Shell-Skripte unter `ci/` — die ganze CI-Logik | Shell | | ~30 Workflow-Dateien | GitHub Actions | | 238 YAML und 26 Helm-Templates | Kubernetes/Helm, YAML | | 26 `values.schema.json` | JSON | | der ganze Baum | Secrets | Der Secrets-Analysator ist der wertvollste Teil: Die Prämisse dieses Repositories ist, dass niemals ein Zugangsdatum darin landet, und bisher prüft das nichts. **Die Scan-Action ist eine JavaScript-Action, keine Docker-Action.** `SonarSource/sonarqube-scan-action@v8.1.0` deklariert `runs: using: node24`. Folgen: - `runs-on: ubuntu-latest` genügt — der Docker-Socket, den nur `ubuntu-docker` hat, ist nicht nötig. - Sie **lädt den Sonar-Scanner-CLI zur Laufzeit** von `binaries.sonarsource.com` und prüft dessen GPG-Signatur. Das ist ein Download in der Größenordnung mehrerer zehn MB über das Netz des Runners. - Sie verlangt **node24** im Runner-Image. Ob das vorhanden ist, ist nicht geprüft. **SonarQube läuft im eigenen Cluster** (`jlab-sonar-db` in cluster-config), und `SONAR_HOST_URL` ist auf der Instanz bereits als **Variable** gesetzt — nicht als Secret, anders als im Schnipsel. ## Entschieden 1. **Als Baustein in `workflow-util/pipelines`.** Der Workflow ist für jedes Repository identisch; das Projektspezifische steht in `sonar-project.properties` im jeweiligen Repo, nicht im Workflow. Damit ist die Wiederverwendung fast kostenlos, und cluster-config sowie die suer-Projekte können ihn sofort mitbenutzen. 2. **Auslöser: nur Push auf `main`.** Lauffähig auf jeder Edition — die Community Build analysiert ausschließlich den Hauptzweig. Folge, die benannt gehört: Ein Befund erscheint **nach** dem Merge. Sonar ist hier eine Beobachtung des Zustands, kein Torwächter. 3. **Kein Quality-Gate-Schritt.** Bei einem Auslöser nach dem Merge gibt es nichts zu blockieren; ein rotes Gate färbte nur `main` rot, und solche Dauerzustände lernt man zu ignorieren. Sinnvoll erst, wenn PR-Analyse möglich ist oder ein Deployment daran hängt. 4. **Kein Ausschluss.** Der ganze Baum, Helm-Templates eingeschlossen. Der erste Lauf zeigt damit auch, was der Helm-Analysator mit Dateien macht, die wegen `{{ }}` kein gültiges YAML sind — eine Information, die wir sonst nie bekommen. ## Aufbau **In `pipelines`:** `.gitea/workflows/sonar-analysis.yml`, `on: workflow_call`. Checkout mit `fetch-depth: 0` (ohne das wird die Zuordnung von Befunden zu Änderungen unbrauchbar), danach die Scan-Action. Beide Actions **auf SHA gepinnt**, wie im Schnipsel — das deckt sich mit der dortigen Hausregel und mit deren offenem Issue #5, das einen wandernden `@master`-Verweis beanstandet. - `SONAR_TOKEN` aus dem Secret des Aufrufers, `SONAR_HOST_URL` aus **`vars`**. - Je ein Wächter für beide, der das Fehlen laut benennt — ein leeres `SONAR_HOST_URL` ergäbe sonst einen Fehler gegen eine Adresse, die niemand sieht; genau dieses Muster haben wir beim Publish-Baustein schon gebraucht. - Eingaben nur als `string`, auch wenn eine inhaltlich ein Schalter ist: Auf dieser Gitea-Fassung kommen boolesche `workflow_call`-Eingaben nachweislich nicht an (dortiges Issue #4, gemessen an 1.27.0, bei grünem Lauf). Vorgesehen sind `args` und `project-base-dir`, beide optional. - **Neuer Tag `v4`**, repository-weit nach der dortigen Konvention. Dass die Nummer den Zustand des Repositories bezeichnet und nicht die Version einer Datei, steht dort seit `v3` dokumentiert. **In `helm-charts`:** `.github/workflows/sonar.yml`, `on: push` auf `main`, Aufruf an `@v4` mit `secrets: inherit`. Dazu `sonar-project.properties` mit Projektschlüssel — Vorschlag `jlab-cluster_helm-charts`, weil die Instanz zwei Eigentümer bedient und ein nackter `helm-charts` beim zweiten kollidieren würde. Falls der Betreuer einen anderen Schlüssel will, wird der genommen. ## Voraussetzungen | Name | Art | Zustand | |---|---|---| | `SONAR_HOST_URL` | Variable | gesetzt | | `SONAR_TOKEN` | Secret | **offen** — muss im aufrufenden Repository oder auf Organisationsebene vorliegen | Das Token braucht in SonarQube das Recht, Analysen auszuführen; soll das Projekt beim ersten Lauf selbst entstehen, zusätzlich das Recht zum Anlegen. ## Was gemessen werden muss, nicht angenommen 1. **Ist node24 im Runner-Image vorhanden?** Die Action verlangt es. Fehlt es, scheitert sie, und zwar mit einer Meldung über die Action, nicht über das Image. 2. **Kommt der Scanner-Download durch?** Das ist die wahrscheinlichste Stelle für den ersten Fehlschlag: In der README dieses Repositories steht gemessen, dass auf diesem Runner einmal eine 17-MB-Datei nicht durchkam, weil die Docker-Brücke mit MTU 1500 gegen ein Pod-Netz mit 1450 lief — kleine Antworten passten in ein Paket, die große nicht. Das wurde auf der Knoten-Seite behoben; der Scanner-CLI ist deutlich größer als 17 MB. 3. **Kommt `vars.SONAR_HOST_URL` in einem aus einem fremden Repository aufgerufenen Workflow an?** Dasselbe Offene wie bei `OP_CONNECT_HOST` im Publish-Baustein — dort ebenfalls noch unbelegt. 4. **Was der erste Lauf tatsächlich meldet**, insbesondere aus den Helm-Templates. Das Ergebnis gehört in den PR-Text, weil es entscheidet, ob Ausschlüsse nachträglich nötig sind. ## Dokumentation In `pipelines`: README-Abschnitt in der dortigen Struktur (Zweck, Eingaben-Tabelle, Aufrufbeispiel, Voraussetzungen) plus Wiki-Seite in der Reihe der Bausteine, und ein Eintrag auf `Gemessenes-Verhalten`, sobald zu node24 oder dem Download etwas gemessen ist. In `helm-charts`: README im CI-Abschnitt und die Wiki-Seite `CI-CD` — was analysiert wird, was nicht blockiert, und dass ein Befund erst nach dem Merge erscheint.

jlab-bot referenced this issue from workflow-util/pipelines

2026-10-02 01:34:28 +02:00

SonarQube-Analyse als geteilten Baustein aufnehmen #8

jlab-bot referenced a pull request that will close this issue

2026-10-02 01:51:10 +02:00

ci: SonarQube-Analyse aufrufen, als Beobachtung und nicht als Torwaechter #73

jklein closed this issue

2026-10-02 01:58:02 +02:00

jlab-bot referenced this issue

2026-10-02 02:04:57 +02:00

Sonar: Projektschluessel korrigieren und den ersten Lauf dokumentieren #74

Sign in to join this conversation.