diff --git a/Gemessenes-Verhalten.md b/Gemessenes-Verhalten.md index cf9b693..02dd3cb 100644 --- a/Gemessenes-Verhalten.md +++ b/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.` 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. diff --git a/sonar-analysis.md b/sonar-analysis.md index 954b158..7ac6edf 100644 --- a/sonar-analysis.md +++ b/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 -ist, ist **nicht geprüft** — siehe unten. +verlangt ihre Node-Hauptversion **im Runner-Image**. Die ist dort vorhanden: +`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 -Infrastruktur, und zwar aus einem konkreten, bereits einmal bezahlten Grund. Im -README des ersten Abnehmers steht gemessen: Auf diesem Runner kam einmal eine +Das war die erwartete Stelle für den ersten Fehlschlag auf dieser Infrastruktur, +und zwar aus einem konkreten, bereits einmal bezahlten Grund. Im README des +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 -beim Download hängt oder abbricht, ist das die erste Spur, die man verfolgt — -und man sucht sie auf der Knoten-Seite, nicht im YAML. +**Der Download kommt durch.** In Lauf 375 waren Archiv und Signatur in etwa drei +Sekunden da; die knotenseitige Behebung hält beim Dreifachen der damaligen +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 -niemand sie zweimal zusammentragen muss, und sie gehört abgearbeitet, sobald der -erste Lauf da ist — die Ergebnisse dann auf -[Gemessenes-Verhalten](Gemessenes-Verhalten). +Diese Liste stand hier mit vier Punkten. **Drei davon hat Lauf 375 des ersten +Abnehmers (`jlab-cluster/helm-charts`, Push auf `main`) beantwortet, alle drei +positiv** — `node24` im Runner-Image, der 59-MiB-Scanner-Download, und dass eine +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 - 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. -2. **Kommt der Scanner-Download durch?** Siehe oben; die wahrscheinlichste - Stelle, und eine mit Vorgeschichte. -3. **Kommt `vars.SONAR_HOST_URL` in einem aus einem fremden Repository - aufgerufenen Workflow an?** Dass der Variablen-Kontext der des Aufrufers - bleibt, ist dokumentiert, auf dieser Forge-Fassung aber nicht gemessen — - dasselbe Offene wie bei `OP_CONNECT_HOST` in - [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 - die Variable. Das Gegenstück dort hat sich für die andere Richtung - entschieden — der Eigentümer ist eine **Eingabe**, weil er im Aufrufer - ausgewertet und nicht auf eine Kontext-Semantik gesetzt wird. Käme `vars` - nicht an, wäre dieselbe Umstellung auch hier der Weg: die Adresse als - Eingabe. -4. **Was der erste Lauf überhaupt meldet**, insbesondere aus Helm-Templates. Der - Helm-Analysator trifft dort auf Dateien, die wegen `{{ }}` kein gültiges YAML - sind. Was er damit macht, bekommt man nur heraus, indem man ihn einmal - darauf laufen lässt — deshalb beginnt der erste Abnehmer **ohne Ausschlüsse**. - Das Ergebnis entscheidet, ob Ausschlüsse nachträglich nötig sind, und es - gehört in die `sonar-project.properties` des jeweiligen Repositories, nicht - in diesen Baustein. +Offen bleibt genau einer, und es ist der inhaltliche: + +1. **Was eine Analyse überhaupt meldet**, insbesondere aus Helm-Templates. Der + Analysator trifft dort auf Dateien, die wegen `{{ }}` kein gültiges YAML + sind. Was er damit macht, bekommt man nur heraus, indem man ihn einmal darauf + laufen lässt — deshalb beginnt der erste Abnehmer **ohne Ausschlüsse**. Das + Ergebnis entscheidet, ob Ausschlüsse nachträglich nötig sind, und es gehört in + die `sonar-project.properties` des jeweiligen Repositories, nicht in diesen + Baustein. + + Lauf 375 hat das **nicht** beantwortet, obwohl der Scan lief: Der Bericht + wurde erzeugt — 603 kB — und nie hochgeladen, weil der Upload an einem + falschen Projektschlüssel scheiterte. Das Protokoll nennt keine + Einzelbefunde. Es braucht also einen erfolgreichen Lauf, nicht nur einen + gestarteten. + +**Eine Sache, die nicht auf der Liste stand und auf ihr hätte stehen müssen: +welche Analysatoren die Instanz tatsächlich hat.** Analysatoren sind +**server-seitige Plugins**; der Scanner lädt eine CLI, keine Sprachen. Eine +Sprachliste aus der Dokumentation beschreibt die neueste SonarQube-Fassung und +sagt über eine konkrete Instanz nichts. Lauf 375 lud **zwei** Qualitätsprofile, +`json` und `yaml`; gearbeitet haben der IaC-Kubernetes-Sensor und die +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.