Sonar: Projektschluessel korrigieren und den ersten Lauf dokumentieren #74

New Issue

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

jlab-bot commented

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

Nachlauf zu #71. Der erste Sonar-Lauf hat stattgefunden (Lauf 375, Push nach main) und drei der vier offenen Fragen beantwortet — alle positiv. Er ist trotzdem rot, und zwar an einem falschen Projektschlüssel.

1. Der Projektschlüssel ist falsch

heute:   sonar.projectKey=jlab-cluster_helm-charts
richtig: sonar.projectKey=JLab-Helm-Charts

Der Wert stammt vom Betreuer; das Projekt existiert in SonarQube unter diesem Schlüssel. Mein Vorschlag jlab-cluster_helm-charts war geraten und hat genau die Meldung erzeugt, die ein nicht vorhandenes Projekt erzeugt:

ERROR You're not authorized to analyze this project or the project doesn't exist
      on SonarQube and you're not authorized to create it.

Dazu sonar.projectName entfernen. Existiert das Projekt auf dem Server, gehört ihm der Anzeigename; ein mitgesendeter Name würde ihn bei jeder Analyse überschreiben. Ein Wert, der stillschweigend fremde Einstellungen umschreibt, ist genau die Sorte, die dieses Repository nicht führt. Begründung als Kommentar in die Datei, sonst ergänzt die nächste Person ihn wieder.

2. Was der Lauf gemessen hat, und wo es hingehört

Alle drei zuvor offenen Punkte sind beantwortet, mit Beleg im Protokoll von Lauf 375:

Frage	Ergebnis
Kommt der Scanner-Download (59 MiB) durch?	Ja — Archiv und Signatur in rund 3 Sekunden. Der MTU-Vorfall von früher wiederholt sich nicht
Ist `node24` im Runner-Image?	Ja, die Action lief
Erreicht `vars.SONAR_HOST_URL` einen aus einem fremden Repository aufgerufenen Workflow?	Ja — sonst hätte der Wächter zugeschlagen und der Scanner wäre nie gestartet

Der dritte Punkt beantwortet eine zweite offene Frage mit: OP_CONNECT_HOST im Publish-Baustein hängt an demselben Mechanismus — eine Repository-Variable, gelesen in einem aus einem fremden Repository aufgerufenen Workflow. Gleiche Gitea-Fassung, gleiche Form. Die Einschränkung auf der Wiki-Seite CI-CD, die das als unbewiesen führt, kann entsprechend umgeschrieben werden.

Diese drei Messungen gehören auf die Seite Gemessenes-Verhalten im Wiki von workflow-util/pipelines; die Abschlussliste der Seite sonar-analysis sagt das selbst und ist danach zu kürzen.

3. Die Analysatoren sind weniger als angekündigt — und das war mein Fehler

Das Issue #71 versprach eine Tabelle mit Shell, GitHub Actions, Kubernetes/Helm, JSON und Secrets. Gemessen geladen wurden zwei Qualitätsprofile, json und yaml; gearbeitet haben der IaC-Kubernetes-Sensor (3,4 s) und der TextAndSecretsSensor über alle 391 Dateien.

Shell und GitHub Actions waren nicht dabei. Die Ursache liegt nicht in unserer Konfiguration: Analysatoren kommen vom Server, nicht vom Scanner, und die Sprachliste, aus der ich zitiert habe, gilt für die neueste Server-Fassung. Die hiesige Instanz hat diese Plugins offenbar nicht.

Folge, die benannt gehört: Die 5 Shell-Skripte unter ci/ und die 30 Workflow-Dateien — die Dateien mit der eigentlichen Logik — werden nicht analysiert. Was läuft, ist IaC auf den Charts und die Geheimnis-Erkennung über alles.

Zu tun: Die Tabelle in README und Wiki auf das korrigieren, was tatsächlich läuft, mit dem Hinweis, woran es hängt. Ob die Instanz aktualisiert oder um Plugins ergänzt wird, ist eine Entscheidung außerhalb dieses Repositories und gehört nicht hierher — ein Verweis darauf genügt.

4. Was die Geheimnis-Erkennung gemeldet hat

Unbekannt: Der Bericht wurde erzeugt (603 kB), aber nie hochgeladen, und das Protokoll nennt keine Einzelbefunde. Nach dem korrigierten Schlüssel zeigt der erste erfolgreiche Lauf es — und das ist der interessanteste Teil, weil die Prämisse dieses Repositories ist, dass kein Zugangsdatum darin liegt.

Nachweis

Nach dem Merge genügt ein workflow_dispatch von sonar.yml — der Auslöser ist dafür eingebaut, es braucht keinen Dummy-Commit. Scheitert es erneut mit derselben Meldung, fehlt dem Token in SonarQube das Recht „Execute Analysis" auf diesem Projekt; das ist dann keine Frage des Schlüssels mehr.

Nachlauf zu #71. Der erste Sonar-Lauf hat stattgefunden (Lauf 375, Push nach `main`) und drei der vier offenen Fragen beantwortet — alle positiv. Er ist trotzdem rot, und zwar an einem falschen Projektschlüssel. ## 1. Der Projektschlüssel ist falsch ``` heute: sonar.projectKey=jlab-cluster_helm-charts richtig: sonar.projectKey=JLab-Helm-Charts ``` Der Wert stammt vom Betreuer; das Projekt existiert in SonarQube unter diesem Schlüssel. Mein Vorschlag `jlab-cluster_helm-charts` war geraten und hat genau die Meldung erzeugt, die ein nicht vorhandenes Projekt erzeugt: ``` ERROR You're not authorized to analyze this project or the project doesn't exist on SonarQube and you're not authorized to create it. ``` **Dazu `sonar.projectName` entfernen.** Existiert das Projekt auf dem Server, gehört ihm der Anzeigename; ein mitgesendeter Name würde ihn bei jeder Analyse überschreiben. Ein Wert, der stillschweigend fremde Einstellungen umschreibt, ist genau die Sorte, die dieses Repository nicht führt. Begründung als Kommentar in die Datei, sonst ergänzt die nächste Person ihn wieder. ## 2. Was der Lauf gemessen hat, und wo es hingehört Alle drei zuvor offenen Punkte sind beantwortet, mit Beleg im Protokoll von Lauf 375: | Frage | Ergebnis | |---|---| | Kommt der Scanner-Download (59 MiB) durch? | **Ja** — Archiv und Signatur in rund 3 Sekunden. Der MTU-Vorfall von früher wiederholt sich nicht | | Ist `node24` im Runner-Image? | **Ja**, die Action lief | | Erreicht `vars.SONAR_HOST_URL` einen aus einem fremden Repository aufgerufenen Workflow? | **Ja** — sonst hätte der Wächter zugeschlagen und der Scanner wäre nie gestartet | **Der dritte Punkt beantwortet eine zweite offene Frage mit:** `OP_CONNECT_HOST` im Publish-Baustein hängt an demselben Mechanismus — eine Repository-Variable, gelesen in einem aus einem fremden Repository aufgerufenen Workflow. Gleiche Gitea-Fassung, gleiche Form. Die Einschränkung auf der Wiki-Seite `CI-CD`, die das als unbewiesen führt, kann entsprechend umgeschrieben werden. Diese drei Messungen gehören auf die Seite `Gemessenes-Verhalten` im Wiki von `workflow-util/pipelines`; die Abschlussliste der Seite `sonar-analysis` sagt das selbst und ist danach zu kürzen. ## 3. Die Analysatoren sind weniger als angekündigt — und das war mein Fehler Das Issue #71 versprach eine Tabelle mit Shell, GitHub Actions, Kubernetes/Helm, JSON und Secrets. Gemessen geladen wurden **zwei Qualitätsprofile, `json` und `yaml`**; gearbeitet haben der **IaC-Kubernetes-Sensor** (3,4 s) und der **TextAndSecretsSensor** über alle 391 Dateien. **Shell und GitHub Actions waren nicht dabei.** Die Ursache liegt nicht in unserer Konfiguration: Analysatoren kommen vom **Server**, nicht vom Scanner, und die Sprachliste, aus der ich zitiert habe, gilt für die neueste Server-Fassung. Die hiesige Instanz hat diese Plugins offenbar nicht. Folge, die benannt gehört: Die 5 Shell-Skripte unter `ci/` und die 30 Workflow-Dateien — die Dateien mit der eigentlichen Logik — werden **nicht** analysiert. Was läuft, ist IaC auf den Charts und die Geheimnis-Erkennung über alles. **Zu tun:** Die Tabelle in README und Wiki auf das korrigieren, was tatsächlich läuft, mit dem Hinweis, woran es hängt. Ob die Instanz aktualisiert oder um Plugins ergänzt wird, ist eine Entscheidung außerhalb dieses Repositories und gehört nicht hierher — ein Verweis darauf genügt. ## 4. Was die Geheimnis-Erkennung gemeldet hat Unbekannt: Der Bericht wurde erzeugt (603 kB), aber nie hochgeladen, und das Protokoll nennt keine Einzelbefunde. Nach dem korrigierten Schlüssel zeigt der erste erfolgreiche Lauf es — und das ist der interessanteste Teil, weil die Prämisse dieses Repositories ist, dass kein Zugangsdatum darin liegt. ## Nachweis Nach dem Merge genügt **ein `workflow_dispatch`** von `sonar.yml` — der Auslöser ist dafür eingebaut, es braucht keinen Dummy-Commit. Scheitert es erneut mit derselben Meldung, fehlt dem Token in SonarQube das Recht „Execute Analysis" auf diesem Projekt; das ist dann keine Frage des Schlüssels mehr.

jklein referenced this issue from a commit

2026-10-02 02:15:13 +02:00

sonar: correct the project key, and record what the first run measured

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

2026-10-02 02:15:41 +02:00

sonar: correct the project key, and record what the first run measured #75

jklein closed this issue

2026-10-02 02:17:47 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#74