Ein CLI-Werkzeug zu einem plattformübergreifenden Downloader hinzufügen und jede Binärdatei prüfen

## Prüfen, ob das Werkzeug statische Binärdateien liefert, und Zielplattformen festlegen Verwende diesen Arbeitsablauf, um ein Befehlszeilenwerkzeug hinzuzufügen, das als direkt ausführbare statische Binärdatei bereitgestellt wird. Verweise Systempakete, die Extraktion von Containerabbildern, Cluster-Erweiterungen und von Laufzeitumgebungen verwaltete Anwendungen auf ihre jeweils eigenen Installationswege. Vergewissere dich vor Codeänderungen, dass für das vorgeschlagene Werkzeug vorkompilierte Veröffentlichungsdateien vorhanden sind. Lehne Pakete ab, die einen Interpreter, eine Paketverwaltung, ein Installationsskript oder eine nicht deklarierte Laufzeitabhängigkeit erfordern. Prüfe, dass der Beitrag nur ein Werkzeug ändert, sofern das Projekt nicht ausdrücklich ein größeres Paket von Änderungen zulässt. Fordere vor der Umsetzung jede projektspezifisch vorgeschriebene Entwurfs- oder Vorgangsfreigabe ein, wenn eine solche Freigabestufe besteht. Erstelle nach der Benennungskonvention des Repositorys einen eng abgegrenzten Zweig. Ermittle den Befehl des Installationsprogramms, den öffentlichen Namen des Werkzeugs sowie Eigentümer und Repository des Ursprungsprojekts. Liste jede Plattformkombination auf, die das Installationsprogramm unterstützen soll. Verwende diese grundlegenden Zielsysteme, sofern das Projekt keine andere Matrix vorgibt: - Linux auf x86-64. - Linux auf ARM64. - macOS auf x86-64. - macOS auf ARM64. - Windows auf x86-64. Gib keine Unterstützung für 32-Bit-x86 oder ARMv6 an, sofern das Installationsprogramm sie nicht ausdrücklich einschließt. Dokumentiere nicht verfügbare Kombinationen, statt sie stillschweigend durch das Artefakt einer anderen Plattform zu ersetzen. ## Vor dem Programmieren die genauen Release-Dateinamen je System und Architektur ermitteln Prüfe die neueste stabile Veröffentlichung des Ursprungsprojekts, bevor du eine Downloadvorlage schreibst. Bevorzuge eine Anfrage, die am Endpunkt für die neueste Veröffentlichung des Ursprungsprojekts nur die Weiterleitung abfragt, damit der Location-Header die Versionsmarke offenlegt. Folge der Weiterleitung nicht, wenn die Marke selbst das benötigte Ergebnis ist. Prüfe für genau diese Marke die vollständig aufgeklappte Dateiliste oder eine andere maßgebliche Veröffentlichungsseite. Vermeide die Nutzung zugriffsbeschränkter APIs, wenn gleichwertige öffentliche Veröffentlichungsmetadaten verfügbar sind. Erfasse jeden veröffentlichten Dateinamen, jedes Archivformat, jedes Betriebssystem und jede Architektur. Bewahre den Wortlaut des Ursprungsprojekts genau, einschließlich Unterscheidungen wie amd64 gegenüber x86_64 und arm64 gegenüber aarch64. Halte für jedes erwartete Ziel fest: - Ob eine Veröffentlichungsdatei vorhanden ist. - Den genauen Dateinamen der Veröffentlichungsdatei. - Den Archivtyp, falls vorhanden. - Den Namen der Binärdatei im Archiv, falls er abweicht. - Jede libc- oder Werkzeugkettenvariante, die die Kompatibilität verändert. Bevorzuge eine portable statische Variante wie musl, wenn das Projekt sie unterstützt und diese Wahl geeignet ist. Behandle Rust-Dateinamen mit Begriffen wie unknown als gültig, wenn sie der Veröffentlichung des Ursprungsprojekts entsprechen. Verwende die ermittelte Matrix als maßgebliche Grundlage für Vorlagen, Tests und Nachweise im Änderungsantrag. ## Jeder Plattform ihre echte Download-URL zuordnen, ohne Ersatzdateien Füge das Werkzeug über die bestehende Definitionsstruktur des Installationsprogramms hinzu und orientiere dich an einem funktionierenden Beispiel in der Nähe. Gib die erforderlichen Identitätsfelder an: Werkzeugname, Eigentümer des Ursprungsprojekts, Repository und kurze Beschreibung. Verwende für einzelne Binärdateien, bei denen die Veröffentlichungsdatei selbst die ausführbare Datei ist, eine Binärdateinamensvorlage. Verwende eine vollständige URL-Vorlage, wenn der Speicherort der Datei eine eigene Pfadlogik erfordert. Ordne jedes unterstützte Betriebssystem und jede Architektur dem tatsächlichen Dateinamen des Ursprungsprojekts zu. Halte die Architekturkonstanten des Installationsprogramms vom Wortlaut der Dateinamen des Ursprungsprojekts getrennt. Verwende eine ausdrückliche Windows-Erkennung, die der Betriebssystemdarstellung der Laufzeitumgebung entspricht. Die unterstützten Archivformen müssen den Dekomprimierungsfähigkeiten des Installationsprogramms entsprechen. Zu den üblicherweise akzeptierten Formen gehören tar.gz, tgz, zip, bz2 und tar.xz. Wenn eine Plattformkombination nicht verfügbar ist, muss ihre erzeugte URL eindeutig fehlschlagen, beispielsweise mit einer Nicht-gefunden-Antwort. Sie darf niemals auf ein Linux-Artefakt, eine andere Architektur oder ein anderes Werkzeug ausweichen. Halte Umwandlungen der Versionsmarke ausdrücklich fest, insbesondere wenn sowohl eine Marke mit Präfix als auch eine numerische Version verwendet werden. Verwende vorhandene Vorlagenvariablen für Betriebssystem, Architektur, Name, Version, Eigentümer und Repository. Schreibe keine aktuelle Version fest in die Produktionsdefinition, wenn das Installationsprogramm die Ersetzung der Version unterstützt. Prüfe die endgültige URL für jede Matrixzeile, bevor du dich auf Tests verlässt. ## Archivnamen und Namen der enthaltenen Binärdatei getrennt angeben Behandle den Namen der Veröffentlichungsdatei und den Namen der ausführbaren Datei in einem Archiv als getrennte Tatsachen. Wenn ein Archiv eine ausführbare Datei mit plattformspezifischem Suffix enthält, definiere beides: - Eine URL-Vorlage, die das herunterladbare Archiv einschließlich seiner Erweiterung bezeichnet. - Eine Binärdateivorlage, die die extrahierte ausführbare Datei ohne die Archiverweiterung bezeichnet. Trage nicht ausschließlich einen Archivdateinamen einschließlich Erweiterung in die Binärdateivorlage ein. Viele Dekomprimierer verwenden die Binärdateivorlage, um die extrahierte Datei zu finden. Eine Archiverweiterung in diesem Feld kann den Rückfall auf den allgemeinen Werkzeugnamen auslösen. Dieser Rückfall schlägt fehl, wenn das Archiv einen plattformspezifischen Binärdateinamen enthält. Für eine einzelne unkomprimierte ausführbare Datei reicht normalerweise eine Binärdateivorlage aus. Bestätige den Unterschied durch Prüfung des Archivs, statt anhand seines Dateinamens zu raten. Prüfe, ob das Archiv der ausführbaren Datei ein Verzeichnispräfix voranstellt. Prüfe, ob ausführbare Windows-Dateien sowohl in der Zuordnung als auch bei der Extraktion das Suffix exe benötigen. Halte die Behandlung von Prüfsummen, Signaturen und Ausführungsberechtigungen im Einklang mit dem bestehenden Installationsprogramm. Wenn die Extraktion eine fehlende Datei meldet, vergleiche diese drei Namen: - Die heruntergeladene Veröffentlichungsdatei. - Das extrahierte Archivelement. - Den vom Installationsprogramm angeforderten Namen. Korrigiere die Zuordnung an der Definitionsgrenze, statt einen weit gefassten Rückfallmechanismus hinzuzufügen. ## Die Download-URL jeder Plattform mit fester Version testen Füge neben den vorhandenen Tests des Downloadprogramms einen eng abgegrenzten Modultest hinzu. Verwende eine festgeschriebene Version des Ursprungsprojekts; teste die URL-Erzeugung niemals gegen latest. Erstelle einen Fall für jede veröffentlichte und unterstützte Kombination aus Betriebssystem und Architektur. Prüfe die vollständige erwartete URL einschließlich Eigentümer, Repository, Marke, Dateiname, Trennzeichen und Archiverweiterung. Übernimm plattformspezifische Architekturaliasnamen genau so, wie das Ursprungsprojekt sie veröffentlicht. Teste besondere Versionsumwandlungen und Windows-Suffixe, sofern vorhanden. Teste bei nicht verfügbaren Kombinationen das vorgesehene Fehlerverhalten des Installationsprogramms, wenn das Rahmenwerk solche Fälle unterstützt. Halte den Test unabhängig von veränderlichen Veröffentlichungsmetadaten. Verwende dieselbe vor der Umsetzung ermittelte Dateimatrix. Führe zuerst die gezielten Pakettests aus. Führe danach, sofern zutreffend, das vom Projekt geforderte umfassendere Prüfziel aus. Ein bestandener URL-Test belegt nur den Aufbau der Zeichenfolge; er belegt nicht, dass die heruntergeladene Datei die richtige Binärdatei ist. ## Die Binärdatei jeder Plattform laden und Format und Architektur prüfen Erstelle das Installationsprogramm vor der plattformübergreifenden Prüfung. Lade zuerst das Artefakt der aktuellen Plattform ohne Überschreibungsoptionen herunter. Prüfe die entstandene Datei, um HTML-Fehlerseiten, mit ausführbaren Dateien verwechselte komprimierte Daten und leere Dateien zu erkennen. Führe das Prüfskript des Repositorys für die Plattformmatrix des Werkzeugs aus. Prüfe jede unterstützte Kombination, nicht nur diejenige des Rechners, der den Test ausführt. Verwende ein Dateierkennungswerkzeug oder einen gleichwertigen Binärdateianalysator, um Format und Architektur zu bestätigen. Typische erwartete Nachweise umfassen: - Linux x86-64 als 64-Bit-ELF-Programmdatei für x86-64. - Linux ARM64 als 64-Bit-ELF-Programmdatei für AArch64. - macOS x86-64 als 64-Bit-Mach-O-Programmdatei für x86-64. - macOS ARM64 als 64-Bit-Mach-O-Programmdatei für ARM64. - Windows x86-64 als PE32+-Konsolenprogrammdatei für x86-64. Eine erfolgreiche HTTP-Antwort reicht nicht aus, weil eine Vorlage die falsche Plattform herunterladen kann. Auch eine erfolgreiche Dekomprimierung reicht nicht aus, weil die enthaltene ausführbare Datei für die falsche Architektur bestimmt sein kann. Erfasse die vollständige Matrixausgabe, ohne Fehler oder Warnungen zu entfernen. Wenn ein Ziel beim Ursprungsprojekt nicht verfügbar ist, prüfe, dass das Installationsprogramm für dieses Ziel fehlschlägt, statt eine inkompatible Binärdatei auszuliefern. Behebe alle Abweichungen vor der Dokumentation oder Freigabe. ## CLI-Katalog neu erzeugen und Prüfergebnisse im Pull Request festhalten Befolge das dokumentierte Verfahren des Repositorys zur Neuerzeugung seines CLI-Katalogs. Erzeuge den Katalog aus dem Installationsprogramm, statt eine Zeile von Hand zu erfinden. Verwende nur dann eine temporäre Arbeitsbereichsdatei, wenn sie für eine sichere Ersetzung erforderlich ist. Bewahre die genauen Anfangs- und Endmarkierungen des Katalogs. Ersetze zwischen diesen Markierungen nur den Inhalt der erzeugten Tabelle und die zugehörige Werkzeuganzahl. Entferne weder den umgebenden Text noch sachfremde Einträge. Bestätige, dass das neue Werkzeug genau einmal mit der erwarteten Beschreibung erscheint. Lösche die temporäre Erzeugungsdatei nach der Aktualisierung. Bereite eine Beschreibung des Änderungsantrags vor, die Folgendes angibt: - Verfügbare und nicht verfügbare Plattformkombinationen. - Die verwendete maßgebliche Veröffentlichungsmarke und das Benennungsmuster. - Die vollständige Ausgabe der Plattformprüfung einschließlich der Binärformate. - Die erforderliche Ausgabe von Ende-zu-Ende-Tests oder umfassenderen Tests, sofern zutreffend. Stelle sicher, dass jeder Commit den vom Repository verlangten Freigabevermerk trägt. Halte die Nachweise reproduzierbar, indem du die Befehle und die festgeschriebene Version nennst. Verschweige in einer Zusammenfassung weder eine fehlende Plattform noch einen fehlgeschlagenen Download oder eine Architekturabweichung. ## Die Änderung prüfen und Download- oder Entpackfehler aufspüren Prüfe Eignung, Zuordnung, Tests, Dokumentation und Nachweise als getrennte Freigabestufen. Bestätige, dass das Werkzeug eine statische Binärdatei ist und die Änderung auf den genehmigten Umfang beschränkt bleibt. Prüfe die erforderlichen Identitätsfelder und stelle sicher, dass mindestens eine gültige Downloadzuordnung vorhanden ist. Vergleiche jeden Vorlagenzweig mit der maßgeblichen Dateimatrix. Prüfe, dass nicht unterstützte Kombinationen keine Binärdatei einer anderen Plattform erhalten können. Bestätige, dass die Modultests eine festgeschriebene Version verwenden und alle unterstützten Ziele abdecken. Fordere vor der Freigabe für jedes angegebene Ziel Nachweise zum Binärformat. Bestätige, dass die erzeugte Dokumentation das Werkzeug enthält und ihre Begrenzungsmarkierungen bewahrt. Untersuche URL-Abweichungen, indem du den genauen Dateinamen des Ursprungsprojekts mit der Umwandlung der Versionsmarke vergleichst. Untersuche falsche Architekturen, indem du die Zweige für Betriebssystem und Architektur unabhängig voneinander nachverfolgst. Untersuche Extraktionsfehler, indem du Archivname, Archivelemente und den konfigurierten Namen der enthaltenen Binärdatei vergleichst. Untersuche Laufzeitfehler, indem du erneut prüfst, ob das Projekt tatsächlich eine eigenständige statische Binärdatei veröffentlicht. Umgehe eine fehlende Datei des Ursprungsprojekts nicht mit einem inkompatiblen Ersatz. Dokumentiere berechtigte Lücken des Ursprungsprojekts im Änderungsantrag. Erteile die Freigabe nur, wenn Code, Tests, heruntergeladene Artefakte, Dokumentation und gemeldete Nachweise übereinstimmen.