Neuer Baustein sonar-analysis.yml, on: workflow_call. Ein Waechter fuer die
Voraussetzungen des Aufrufers, Checkout mit vollstaendiger Historie, dann die
offizielle Scan-Action. Beide Actions auf einen Commit gepinnt.
Projektspezifisches steht in der sonar-project.properties des aufrufenden
Repositories, nicht hier - damit ist der Workflow fuer jedes Repository
identisch und ein zweiter Abnehmer kostet eine Datei mit drei Zeilen.
Kein Quality-Gate-Schritt, und das absichtlich: Die Community Build analysiert
nur den Hauptzweig, der Ausloeser liegt damit nach dem Merge, und dort ist
nichts mehr zu blockieren. Ein rotes main ohne Wirkung nimmt die
Glaubwuerdigkeit der uebrigen Pruefungen mit. Die zwei Bedingungen, unter denen
ein Gate richtig waere, stehen im README und als Kommentar an der Stelle, an
der der Schritt stuende.
SONAR_HOST_URL ist eine Variable des Aufrufers, SONAR_TOKEN sein Secret. Die
Adresse bleibt als Variable im Protokoll lesbar - erst das macht eine falsche
Adresse diagnostizierbar. Der Waechter prueft beide, bevor er abbricht, damit
ein Repository ohne beide das in einem Lauf erfaehrt.
Beide Eingaben sind type: string, auch project-base-dir: Boolesche
workflow_call-Eingaben kommen auf dieser Gitea-Version nicht an (Issue #4), und
die Regel gilt fuer jede Eingabe hier, damit sie nicht je Datei neu entschieden
wird.
Die Langform - warum fetch-depth: 0 nicht optional ist, warum kein
Docker-Runner noetig ist, was der Scanner zur Laufzeit holt und was an diesem
Baustein noch nicht gemessen ist - steht im Wiki unter sonar-analysis.
Der Baustein ist ab v4 verfuegbar; die Tag-Nummer bezeichnet wie bisher den
Zustand des Repositories und nicht die Version einer Datei.
Das Wiki dieses Repositories ist jetzt angelegt und traegt die Langform zu
beiden Bausteinen. Ohne einen Verweis von hier aus erfaehrt davon niemand, der
nur das README liest.
Die Aufteilung steht dabei gleich mit: Diese Datei bleibt die Kurzreferenz fuer
Aufrufer und wird nicht gekuerzt, das Wiki begruendet sie.
Part of jlab-cluster/helm-charts#66
Der Workflow kommt aus jlab-cluster/helm-charts, wo er 26 duenne Huellen
bedient. Er laedt ein gepacktes Chart in eine klassische, indexbasierte
Helm-Registry: ein einzelnes HTTP-POST, kein OCI-helm-push.
Zwei Dinge sind beim Umzug anders als in der Vorlage.
Der Eigentuemer ist eine Pflichteingabe registry-owner vom Typ string, ohne
Vorgabe. Bisher wurde er aus github.repository_owner abgeleitet; als Eingabe
wird er im aufrufenden Repository ausgewertet, wo der Wert gemessen ist. Das
folgt der Hausregel, dass ein Eigentuemer-Segment nie geraten wird, und haengt
den Baustein an keine Kontext-Semantik. type: string wie alle Eingaben hier,
siehe #4.
OP_CONNECT_HOST kommt aus einer Variablen des aufrufenden Repositories statt
fest verdrahtet aus dem Baustein — ein geteilter Baustein traegt nicht die
Infrastruktur-Adresse eines einzelnen Mandanten. Ein erster Schritt prueft die
Variable und benennt sie beim Abbruch, statt zwei Schritte spaeter an einer
leeren Adresse zu scheitern.
Alles andere ist unveraendert uebernommen, samt der Kommentare, die es
begruenden: curl --config - statt --user, --fail-with-body, der gebaute
Dateiname mit test -f, die :?-Waechter je Tresor-Feld, die Leerzeichen-Pruefung
an den Zugangsdaten, das Maskieren des Hosts und die drei Formwaechter an
charts-url.
Der workflow_dispatch-Block ist entfallen: Ein Dispatch hier liefe gegen dieses
Repository, in dem kein Chart liegt. Die Huellen des Aufrufers tragen ihn.
ci/helm-dependencies.sh bleibt ein Skript des aufrufenden Repositories; der
Checkout holt dessen Baum, also laeuft es weiter aus dessen Kopie.
Part of jlab-cluster/helm-charts#66
jklein