Die drei Messungen aus Lauf 375 aufnehmen, die Offen-Liste kuerzen

Lauf 375 des ersten Abnehmers (jlab-cluster/helm-charts, Push auf main) hat
drei der vier offenen Punkte von sonar-analysis beantwortet, alle drei positiv.
Sie stehen jetzt auf Gemessenes-Verhalten, wo Gemessenes hingehoert:

- Eine Repository-Variable erreicht einen aus einem fremden Repository
  aufgerufenen Workflow. Der Beleg ist der Waechter, der durchlief, und der
  Scanner, der startete. Damit ist dieselbe Frage fuer OP_CONNECT_HOST in
  publish-helm-chart beantwortet; offen bleibt dort nur noch der Upload selbst.
- Der 59-MiB-Scanner-Download kommt durch, Archiv und Signatur in etwa drei
  Sekunden. Der MTU-Vorfall mit der 17-MB-Datei wiederholt sich nicht; die
  knotenseitige Behebung haelt beim Dreifachen der Groesse.
- node24 ist im Runner-Image vorhanden, die JavaScript-Action lief.

Dazu ein Satz im Vorspann, dass auch Bestaetigungen auf die Seite gehoeren: Eine
ungeschriebene harmlose Eigenheit kostet dieselbe zweite Messung wie eine
gefaehrliche.

Die Abschlussliste von sonar-analysis ist von vier Punkten auf einen gekuerzt.
Offen bleibt, was eine Analyse ueberhaupt meldet - Lauf 375 hat das nicht
beantwortet, obwohl der Scan lief: Der Bericht wurde erzeugt (603 kB) und nie
hochgeladen. Neu dort der Punkt, der von Anfang an auf der Liste gehoert
haette: welche Analysatoren die Instanz tatsaechlich hat. Analysatoren sind
server-seitige Plugins, und eine Sprachliste aus der Dokumentation sagt darueber
nichts.

Gemessenes-Verhalten.md

@@ -9,6 +9,12 @@ Gemeinsames Muster, das sie teuer macht: Keiner dieser Fehler ist rot. Der Lauf
 bleibt grün oder sieht harmlos aus, und erst viel später sucht jemand das
 Ergebnis dort, wo es hätte landen sollen.
 
+Es stehen auch **Bestätigungen** hier, nicht nur Fallen. Eine Eigenheit, die
+sich als harmlos herausgestellt hat, kostet ungeschrieben dasselbe wie eine
+gefährliche: Die nächste Person misst sie erneut, oder — schlimmer — baut einen
+Umweg um ein Problem, das es nicht gibt. Jeder Eintrag nennt deshalb den Lauf,
+an dem er gemessen ist.
+
 ## Boolesche `workflow_call`-Eingaben kommen nicht an
 
 Gemessen an **Gitea 1.27.0**,
@@ -93,3 +99,65 @@ auf einen Zweig, während die übrigen Actions auf Hauptversionen gepinnt sind.
 Festgehalten als bekannte Schwachstelle unter
 [docker-build-push](docker-build-push), damit sie nicht erneut entdeckt werden
 muss.
+
+## Eine Repository-Variable erreicht einen fremd aufgerufenen Workflow
+
+Gemessen in `jlab-cluster/helm-charts`, **Lauf 375** (Push auf `main`), an
+[sonar-analysis](sonar-analysis).
+
+`vars.<NAME>` wird in einem Workflow, der per `uses:` aus einem **anderen**
+Repository geholt wird, im Kontext des **Aufrufers** aufgelöst. Dass es so
+dokumentiert ist, war bekannt; auf dieser Forge-Fassung gemessen war es nicht.
+
+Der Beleg ist indirekt und trotzdem eindeutig: `sonar-analysis` prüft
+`vars.SONAR_HOST_URL` in einem Wächter und bricht **vor** dem Scan ab, wenn der
+Wert leer ist. In Lauf 375 ist der Wächter durchgelaufen und der Scanner
+gestartet — bei leerer Variable hätte es den Scan nie gegeben. Dasselbe gilt für
+das `uses:` selbst: Der Baustein liegt in diesem Repository, der Aufruf kam aus
+einem anderen, und er wurde aufgelöst.
+
+**Damit ist dieselbe Frage für `OP_CONNECT_HOST` in
+[publish-helm-chart](publish-helm-chart) beantwortet.** Gleiche Gitea-Fassung,
+gleicher Mechanismus: eine Repository-Variable, gelesen in einem aus einem
+fremden Repository aufgerufenen Workflow. Dort muss nichts zweites gemessen
+werden, und der vorgesehene Ausweg — die Adresse als **Eingabe** übergeben, im
+Aufrufer ausgewertet, wie es für das Eigentümer-Segment schon getan wurde —
+wird nicht gebraucht.
+
+Was an der Publish-Strecke offen bleibt, ist etwas anderes und nur das: **der
+Upload selbst hat nie stattgefunden.** Kein Chart ist durch den geteilten
+Baustein veröffentlicht worden.
+
+## Der Scanner-Download kommt durch — 59 MiB in etwa drei Sekunden
+
+Gemessen in `jlab-cluster/helm-charts`, **Lauf 375**.
+
+`SonarSource/sonarqube-scan-action` lädt den Sonar-Scanner-CLI zur Laufzeit von
+`binaries.sonarsource.com` und prüft dessen GPG-Signatur. Archiv und Signatur,
+rund **59 MiB**, waren in etwa **drei Sekunden** da.
+
+Das war die erwartete Stelle für den ersten Fehlschlag, und zwar mit
+Vorgeschichte: Auf demselben Runner kam einmal eine **17-MB-Datei nicht durch**,
+weil die Docker-Brücke mit MTU 1500 gegen ein Pod-Netz mit MTU 1450 lief —
+kleine Antworten passten in ein Paket, die große nicht, und der Fehlschlag sah
+nach einem kaputten Spiegel aus, nicht nach Netz. Festgehalten im README von
+`jlab-cluster/helm-charts`, Abschnitt „What a GitHub runner had been providing
+quietly".
+
+**Die knotenseitige Behebung hält, und sie hält beim Dreifachen der damaligen
+Größe.** Ein Download in dieser Größenordnung ist auf diesem Runner kein Risiko
+mehr und braucht keinen Zwischenspeicher und keinen eigenen Spiegel.
+
+## `node24` ist im Runner-Image vorhanden
+
+Gemessen in `jlab-cluster/helm-charts`, **Lauf 375**.
+
+`SonarSource/sonarqube-scan-action` deklariert `runs: using: node24` und ist
+damit eine JavaScript-Action, keine Docker-Action. Sie lief. Zwei Folgen:
+
+- **JavaScript-Actions mit `node24` sind hier benutzbar.** Fehlte die
+  Laufzeitumgebung, scheiterte die Action mit einer Meldung über **sich selbst**
+  und nicht über das Image — deshalb stand die Frage vorher aufgeschrieben.
+- `runs-on: ubuntu-latest` genügt für so eine Action. Das Label
+  `ubuntu-docker`, das den Docker-Socket mitbringt, braucht nur, wer wirklich
+  eine Docker-Action oder einen Build ausführt.

sonar-analysis.md

@@ -63,8 +63,9 @@ im Node des Runners und nicht in einem Container. Kein Socket, kein Daemon,
 `ubuntu-latest` genügt.
 
 Das hat eine Kehrseite, die man im Blick behalten muss. Eine JavaScript-Action
-verlangt ihre Node-Hauptversion **im Runner-Image**. Ob diese dort vorhanden
+verlangt ihre Node-Hauptversion **im Runner-Image**. Die ist dort vorhanden:
-ist, ist **nicht geprüft** — siehe unten.
+`node24` ist in Lauf 375 gemessen, siehe
+[Gemessenes-Verhalten](Gemessenes-Verhalten).
 
 ## Was der Scanner zur Laufzeit holt
 
@@ -73,17 +74,20 @@ Lauf** von `binaries.sonarsource.com` und prüft dessen GPG-Signatur. Das ist
 nichts Kleines: Bei der Messung für diese Seite lag das Linux-Archiv bei rund
 **59 MiB** (`Content-Length` 61 626 644).
 
-Damit ist das die wahrscheinlichste Stelle für den ersten Fehlschlag auf dieser
+Das war die erwartete Stelle für den ersten Fehlschlag auf dieser Infrastruktur,
-Infrastruktur, und zwar aus einem konkreten, bereits einmal bezahlten Grund. Im
+und zwar aus einem konkreten, bereits einmal bezahlten Grund. Im README des
-README des ersten Abnehmers steht gemessen: Auf diesem Runner kam einmal eine
+ersten Abnehmers steht gemessen: Auf diesem Runner kam einmal eine
 **17-MB-Datei nicht durch**, weil eine Docker-Brücke mit MTU 1500 gegen ein
 Pod-Netz mit 1450 lief. Kleine Antworten passten in ein Paket, die große nicht —
 und es sah aus wie ein gesperrter Host, nicht wie ein MTU-Problem. Behoben wurde
 das auf der Knoten-Seite, nicht in einem Workflow.
 
-Der Scanner-CLI ist ein Mehrfaches dieser 17 MB. Wenn ein Lauf dieses Bausteins
+**Der Download kommt durch.** In Lauf 375 waren Archiv und Signatur in etwa drei
-beim Download hängt oder abbricht, ist das die erste Spur, die man verfolgt —
+Sekunden da; die knotenseitige Behebung hält beim Dreifachen der damaligen
-und man sucht sie auf der Knoten-Seite, nicht im YAML.
+Größe. Nachzulesen unter [Gemessenes-Verhalten](Gemessenes-Verhalten). Wenn ein
+Lauf dieses Bausteins trotzdem einmal beim Download hängt oder abbricht, ist die
+MTU-Geschichte die erste Spur, die man verfolgt — und man sucht sie auf der
+Knoten-Seite, nicht im YAML.
 
 Zwei weitere Folgen des Laufzeit-Downloads, nebenbei: Der Baustein hängt an der
 Erreichbarkeit eines fremden Hosts, und er hängt an einer Signaturprüfung. Beide
@@ -144,31 +148,39 @@ und ändert das Verhalten aller Aufrufer, ohne dass hier etwas angefasst wurde.
 
 ## Was an diesem Baustein nicht gemessen ist
 
-Diese Liste ist der eigentliche Grund für die Seite. Sie steht hier, damit
+Diese Liste stand hier mit vier Punkten. **Drei davon hat Lauf 375 des ersten
-niemand sie zweimal zusammentragen muss, und sie gehört abgearbeitet, sobald der
+Abnehmers (`jlab-cluster/helm-charts`, Push auf `main`) beantwortet, alle drei
-erste Lauf da ist — die Ergebnisse dann auf
+positiv** — `node24` im Runner-Image, der 59-MiB-Scanner-Download, und dass eine
-[Gemessenes-Verhalten](Gemessenes-Verhalten).
+Repository-Variable einen aus einem fremden Repository aufgerufenen Workflow
+erreicht. Sie stehen jetzt dort, wo Gemessenes hingehört: auf
+[Gemessenes-Verhalten](Gemessenes-Verhalten), mit je einem Abschnitt. Der dritte
+hat dabei dieselbe Frage für `OP_CONNECT_HOST` in
+[publish-helm-chart](publish-helm-chart) mitbeantwortet.
 
-1. **Ist `node24` im Runner-Image vorhanden?** Die Scan-Action verlangt es. Wenn
+Offen bleibt genau einer, und es ist der inhaltliche:
-   nicht, scheitert sie — und zwar mit einer Meldung über die Action, nicht über
+
-   das Image. Wer das ohne diese Zeile liest, sucht den Fehler in der Action.
+1. **Was eine Analyse überhaupt meldet**, insbesondere aus Helm-Templates. Der
-2. **Kommt der Scanner-Download durch?** Siehe oben; die wahrscheinlichste
+   Analysator trifft dort auf Dateien, die wegen `{{ }}` kein gültiges YAML
-   Stelle, und eine mit Vorgeschichte.
+   sind. Was er damit macht, bekommt man nur heraus, indem man ihn einmal darauf
-3. **Kommt `vars.SONAR_HOST_URL` in einem aus einem fremden Repository
+   laufen lässt — deshalb beginnt der erste Abnehmer **ohne Ausschlüsse**. Das
-   aufgerufenen Workflow an?** Dass der Variablen-Kontext der des Aufrufers
+   Ergebnis entscheidet, ob Ausschlüsse nachträglich nötig sind, und es gehört in
-   bleibt, ist dokumentiert, auf dieser Forge-Fassung aber nicht gemessen —
+   die `sonar-project.properties` des jeweiligen Repositories, nicht in diesen
-   dasselbe Offene wie bei `OP_CONNECT_HOST` in
+   Baustein.
-   [publish-helm-chart](publish-helm-chart), wo es ebenfalls noch unbelegt ist.
+
-   Wenn es nicht ankommt, ist das immerhin laut: Der Wächter greift und benennt
+   Lauf 375 hat das **nicht** beantwortet, obwohl der Scan lief: Der Bericht
-   die Variable. Das Gegenstück dort hat sich für die andere Richtung
+   wurde erzeugt — 603 kB — und nie hochgeladen, weil der Upload an einem
-   entschieden — der Eigentümer ist eine **Eingabe**, weil er im Aufrufer
+   falschen Projektschlüssel scheiterte. Das Protokoll nennt keine
-   ausgewertet und nicht auf eine Kontext-Semantik gesetzt wird. Käme `vars`
+   Einzelbefunde. Es braucht also einen erfolgreichen Lauf, nicht nur einen
-   nicht an, wäre dieselbe Umstellung auch hier der Weg: die Adresse als
+   gestarteten.
-   Eingabe.
+
-4. **Was der erste Lauf überhaupt meldet**, insbesondere aus Helm-Templates. Der
+**Eine Sache, die nicht auf der Liste stand und auf ihr hätte stehen müssen:
-   Helm-Analysator trifft dort auf Dateien, die wegen `{{ }}` kein gültiges YAML
+welche Analysatoren die Instanz tatsächlich hat.** Analysatoren sind
-   sind. Was er damit macht, bekommt man nur heraus, indem man ihn einmal
+**server-seitige Plugins**; der Scanner lädt eine CLI, keine Sprachen. Eine
-   darauf laufen lässt — deshalb beginnt der erste Abnehmer **ohne Ausschlüsse**.
+Sprachliste aus der Dokumentation beschreibt die neueste SonarQube-Fassung und
-   Das Ergebnis entscheidet, ob Ausschlüsse nachträglich nötig sind, und es
+sagt über eine konkrete Instanz nichts. Lauf 375 lud **zwei** Qualitätsprofile,
-   gehört in die `sonar-project.properties` des jeweiligen Repositories, nicht
+`json` und `yaml`; gearbeitet haben der IaC-Kubernetes-Sensor und die
-   in diesen Baustein.
+Geheimnis-Erkennung. Shell und GitHub Actions waren nicht dabei, obwohl der
+erste Abnehmer dafür geplant war. **Jeder Aufrufer dieses Bausteins muss also
+damit rechnen, dass ein Teil seines Baums ungeprüft bleibt** — und was geprüft
+wird, steht erst nach dem ersten Lauf fest. Dieser Baustein kann daran nichts
+ändern, und `sonar-project.properties` auch nicht.