Ajouter un outil CLI à un téléchargeur multiplateforme et vérifier chaque binaire

## Vérifier que l'outil fournit des binaires statiques et fixer les plateformes Utilisez ce processus pour ajouter un outil en ligne de commande distribué sous forme de binaire statique directement exécutable. Orientez les paquets système, l'extraction d'images de conteneur, les modules complémentaires de grappe et les applications gérées par un environnement d'exécution vers leurs propres voies d'installation. Vérifiez que l'outil proposé dispose de ressources de version précompilées avant de modifier le code. Rejetez les paquets qui nécessitent un interpréteur, un gestionnaire de paquets, un script d'installation ou une dépendance d'exécution non déclarée. Vérifiez que la contribution ne modifie qu'un seul outil, sauf si le projet autorise explicitement un lot plus large. Exigez avant la mise en œuvre toute approbation de conception ou de demande propre au projet lorsqu'un tel contrôle existe. Créez une branche ciblée conforme à la convention de nommage du dépôt. Identifiez la commande du programme d'installation, le nom public de l'outil ainsi que le propriétaire et le dépôt du projet d'origine. Répertoriez toutes les combinaisons de plateformes que le programme d'installation doit prendre en charge. Utilisez ces cibles de référence, sauf si le projet définit une autre matrice : - Linux sur x86-64. - Linux sur ARM64. - macOS sur x86-64. - macOS sur ARM64. - Windows sur x86-64. Ne revendiquez pas la prise en charge de l'architecture 32 bits x86 ou ARMv6, sauf si le programme d'installation les inclut explicitement. Consignez les combinaisons indisponibles au lieu de leur substituer silencieusement l'artefact d'une autre plateforme. ## Relever les noms exacts des fichiers publiés pour chaque système et architecture avant de programmer Examinez la dernière version stable du projet d'origine avant de rédiger un modèle de téléchargement. Privilégiez une requête limitée à la redirection vers le point de terminaison de la dernière version du projet d'origine, afin que l'en-tête Location révèle l'étiquette de version. Ne suivez pas la redirection lorsque l'étiquette elle-même constitue le résultat requis. Examinez la liste complète des ressources ou une autre page de version faisant autorité pour cette étiquette précise. Évitez de solliciter des API soumises à des limites de requêtes lorsque des métadonnées publiques de version équivalentes sont disponibles. Répertoriez chaque nom de fichier, format d'archive, système d'exploitation et architecture publiés. Conservez exactement la terminologie du projet d'origine, notamment les distinctions comme amd64 par rapport à x86_64 et arm64 par rapport à aarch64. Pour chaque cible prévue, consignez : - L'existence ou non d'une ressource. - Le nom exact du fichier de la ressource. - Le type d'archive, le cas échéant. - Le nom du binaire dans l'archive, s'il est différent. - Toute variante de libc ou de chaîne d'outils qui modifie la compatibilité. Privilégiez une variante statique portable comme musl lorsque le projet la prend en charge et que ce choix est approprié. Considérez comme valides les noms de fichiers Rust contenant des termes comme unknown lorsqu'ils correspondent à la version du projet d'origine. Utilisez la matrice recueillie comme source de référence pour les modèles, les tests et les preuves de la demande d'intégration. ## Associer chaque plateforme à sa vraie URL de téléchargement, sans substitut Ajoutez l'outil au moyen de la structure de définition établie du programme d'installation et suivez un exemple fonctionnel proche. Fournissez les champs d'identité obligatoires : nom de l'outil, propriétaire du projet d'origine, dépôt et description concise. Utilisez un modèle de nom de fichier binaire pour les binaires simples dont la ressource de version est l'exécutable lui-même. Utilisez un modèle d'URL complet lorsque l'emplacement de la ressource nécessite une logique de chemin personnalisée. Associez chaque système d'exploitation et chaque architecture pris en charge à son véritable nom de fichier dans le projet d'origine. Séparez les constantes d'architecture du programme d'installation de la terminologie des noms de fichiers du projet d'origine. Utilisez une détection explicite de Windows qui corresponde à la représentation du système d'exploitation par l'environnement d'exécution. Les formes d'archives prises en charge doivent correspondre aux capacités de décompression du programme d'installation. Les formes couramment acceptées comprennent tar.gz, tgz, zip, bz2 et tar.xz. Lorsqu'une combinaison de plateformes est indisponible, son URL générée doit échouer clairement, par exemple avec une réponse indiquant une ressource introuvable. Elle ne doit jamais se rabattre sur un artefact Linux, une autre architecture ou un autre outil. Rendez explicites les transformations de l'étiquette de version, surtout lorsqu'une étiquette préfixée et une version numérique sont toutes deux utilisées. Utilisez les variables de modèle existantes pour le système d'exploitation, l'architecture, le nom, la version, le propriétaire et le dépôt. N'inscrivez pas en dur une version actuelle dans la définition de production lorsque le programme d'installation permet de remplacer la version. Examinez l'URL finale de chaque ligne de la matrice avant de vous fier aux tests. ## Séparer le nom de l'archive du nom du binaire qu'elle contient Traitez le nom de la ressource de version et celui de l'exécutable dans une archive comme des faits distincts. Si une archive contient un exécutable doté d'un suffixe de plateforme, définissez les deux éléments : - Un modèle d'URL qui nomme l'archive téléchargeable, extension comprise. - Un modèle de binaire qui nomme l'exécutable extrait sans l'extension de l'archive. Ne placez pas uniquement dans le modèle de binaire le nom d'un fichier d'archive avec son extension. De nombreux décompresseurs utilisent le modèle de binaire pour localiser le fichier extrait. Une extension d'archive dans ce champ peut déclencher un repli sur le nom générique de l'outil. Ce repli échoue lorsque l'archive contient un nom de binaire propre à la plateforme. Pour un exécutable simple et non compressé, un modèle de binaire seul suffit normalement. Confirmez cette distinction en inspectant l'archive plutôt qu'en la déduisant de son nom de fichier. Vérifiez si l'archive ajoute un préfixe de répertoire autour de l'exécutable. Vérifiez si les exécutables Windows nécessitent le suffixe exe à la fois dans la correspondance et dans l'extraction. Maintenez le traitement des sommes de contrôle, des signatures et des autorisations d'exécution cohérent avec le programme d'installation existant. Si l'extraction signale un fichier manquant, comparez ces trois noms : - La ressource téléchargée. - Le membre extrait de l'archive. - Le nom demandé par le programme d'installation. Corrigez la correspondance à la limite de la définition au lieu d'ajouter un mécanisme de repli général. ## Tester l'URL de téléchargement de chaque plateforme avec une version fixe Ajoutez un test unitaire ciblé à côté des tests existants du téléchargeur. Utilisez une version figée du projet d'origine ; ne testez jamais la génération d'URL avec latest. Créez un cas pour chaque combinaison publiée et prise en charge de système d'exploitation et d'architecture. Vérifiez l'URL attendue complète, notamment le propriétaire, le dépôt, l'étiquette, le nom de fichier, les séparateurs et l'extension de l'archive. Incluez les alias d'architecture propres à chaque plateforme exactement tels que les publie le projet d'origine. Testez les transformations particulières de version et les suffixes Windows lorsqu'ils existent. Pour les combinaisons indisponibles, testez le comportement d'échec prévu du programme d'installation lorsque le cadre logiciel prend en charge ces cas. Gardez le test indépendant des métadonnées de version susceptibles de changer. Utilisez la même matrice de ressources que celle recueillie avant la mise en œuvre. Exécutez d'abord les tests ciblés du paquet. Exécutez ensuite la cible de test plus large exigée par le projet, le cas échéant. La réussite d'un test d'URL prouve uniquement la construction de la chaîne ; elle ne prouve pas que le fichier téléchargé est le bon binaire. ## Télécharger le binaire de chaque plateforme et vérifier format et architecture Compilez le programme d'installation avant la vérification multiplateforme. Téléchargez d'abord l'artefact de la plateforme actuelle sans options de forçage. Inspectez le fichier obtenu afin de détecter les pages d'erreur HTML, les données compressées prises pour des exécutables et les fichiers vides. Exécutez pour l'outil le script de vérification de la matrice des plateformes du dépôt. Vérifiez toutes les combinaisons prises en charge, et pas seulement celle de la machine qui exécute le test. Utilisez un outil d'identification de fichiers ou un analyseur de binaires équivalent pour confirmer le format et l'architecture. Les preuves attendues comprennent généralement : - Linux x86-64 sous forme d'exécutable ELF 64 bits pour x86-64. - Linux ARM64 sous forme d'exécutable ELF 64 bits pour AArch64. - macOS x86-64 sous forme d'exécutable Mach-O 64 bits pour x86-64. - macOS ARM64 sous forme d'exécutable Mach-O 64 bits pour ARM64. - Windows x86-64 sous forme d'exécutable de console PE32+ pour x86-64. Une réponse HTTP réussie est insuffisante, car un modèle peut télécharger la mauvaise plateforme. Une décompression réussie est également insuffisante, car l'exécutable interne peut cibler la mauvaise architecture. Capturez la sortie complète de la matrice sans supprimer les échecs ni les avertissements. Si une cible n'est pas disponible dans le projet d'origine, vérifiez que le programme d'installation échoue pour cette cible au lieu de fournir un binaire incompatible. Résolvez toutes les divergences avant la documentation ou l'approbation. ## Régénérer le catalogue CLI et noter les résultats dans la pull request Suivez le processus documenté du dépôt pour régénérer son catalogue CLI. Générez le catalogue depuis le programme d'installation au lieu d'inventer manuellement une ligne. Utilisez un fichier temporaire de l'espace de travail uniquement lorsqu'il est nécessaire à un remplacement sûr. Conservez exactement les marqueurs de début et de fin du catalogue. Remplacez uniquement le contenu de la table générée et le nombre d'outils associé entre ces marqueurs. Ne supprimez ni le texte environnant ni les entrées sans rapport. Vérifiez que le nouvel outil apparaît une seule fois avec la description attendue. Supprimez le fichier temporaire de génération après la mise à jour. Préparez une description de la demande d'intégration qui indique : - Les combinaisons de plateformes disponibles et indisponibles. - L'étiquette de version faisant autorité et le modèle de nommage utilisés. - La sortie complète de la vérification des plateformes, y compris les formats binaires. - La sortie requise des tests de bout en bout ou des tests plus larges, le cas échéant. Veillez à ce que chaque commit comporte la validation exigée par le dépôt. Gardez les preuves reproductibles en indiquant les commandes et la version figée. Ne masquez pas dans un résumé une plateforme manquante, un téléchargement échoué ou une divergence d'architecture. ## Examiner la modification et trouver la cause des échecs de téléchargement ou d'extraction Examinez séparément l'admissibilité, la correspondance, les tests, la documentation et les preuves. Vérifiez que l'outil est un binaire statique et que la modification reste limitée au périmètre approuvé. Contrôlez les champs d'identité obligatoires et assurez-vous qu'il existe au moins une correspondance de téléchargement valide. Comparez chaque branche du modèle à la matrice de ressources faisant autorité. Vérifiez que les combinaisons non prises en charge ne peuvent pas recevoir le binaire d'une autre plateforme. Confirmez que les tests unitaires utilisent une version figée et couvrent toutes les cibles prises en charge. Exigez des preuves du format binaire pour chaque cible déclarée avant approbation. Vérifiez que la documentation générée comprend l'outil et conserve ses marqueurs de délimitation. Recherchez les causes des divergences d'URL en comparant le nom de fichier exact du projet d'origine à la transformation de l'étiquette. Recherchez les causes des architectures incorrectes en suivant séparément les branches du système d'exploitation et de l'architecture. Recherchez les causes des échecs d'extraction en comparant le nom de l'archive, ses membres et le nom configuré du binaire interne. Recherchez les causes des échecs d'exécution en réexaminant si le projet distribue réellement un binaire statique autonome. Ne contournez pas l'absence d'une ressource du projet d'origine avec un substitut incompatible. Documentez dans la demande d'intégration les lacunes légitimes du projet d'origine. N'approuvez que lorsque le code, les tests, les artefacts téléchargés, la documentation et les preuves communiquées concordent.