Modifier un grand monorepo de plateforme de données multilingue et préparer les pull requests

## Vérifier les remotes Git et choisir la bonne branche avant la première modification Avant la première modification ou le premier test d’une session : 1. identifiez le fork personnel et les remotes upstream faisant autorité ; si leur rôle n’est pas clair, demandez la configuration de l’agencement standard des remotes ; 2. vérifiez l’horodatage de la branche par défaut de l’upstream et actualisez-la lorsque la référence locale est obsolète ; 3. inspectez l’arbre de travail et demandez à l’utilisateur de protéger les modifications non validées avant de changer de contexte ; 4. choisissez la branche en fonction de la tâche. Pour une revue existante, déterminez sa branche head, utilisez une branche locale correspondante lorsqu’elle existe et signalez le changement. S’il n’existe aucune correspondance, demandez s’il faut récupérer la branche ou utiliser une branche locale portant un autre nom. Pour de nouvelles modifications, proposez comme option recommandée un worktree isolé créé à partir de la branche par défaut de l’upstream, ou une nouvelle branche basée sur celle-ci. Pour un travail limité aux tests, utilisez la branche par défaut de l’upstream. ## Régénérer les sorties de référence des tests et les fichiers de protocole au lieu de les modifier Les sorties de référence des tests appartiennent au banc de test qui les génère. Lisez la documentation de la suite avant de les exécuter ou de les actualiser, ne modifiez jamais directement les fichiers générés de résultats attendus et régénérez-les au moyen du flux de travail pris en charge. Examinez soigneusement la différence obtenue avant de l’accepter. Les définitions du protocole appartiennent à leur source de schéma. Lisez la documentation stockée avec ces définitions avant de modifier des messages ou des champs et excluez les artefacts de protocole générés des modifications manuelles. ## Garder le code en ASCII et sous la limite de longueur de ligne avant la CI Conservez les identifiants, le code et les commentaires en ASCII, sauf si le contenu d’un littéral de chaîne ou d’un fixture de test exige réellement d’autres caractères. Vérifiez ponctuellement que les fichiers modifiés ne contiennent pas de tirets typographiques, de guillemets courbes, de points de suspension ni d’espaces insécables, qui se glissent souvent dans les commentaires sans être remarqués. Maintenez les lignes du code source sous la limite du dépôt, généralement fixée à 100 caractères. Une analyse rapide des fichiers source ajoutés et modifiés peut estimer les exceptions concernant les imports, les déclarations de package et les URL, mais elle ne fournit qu’un indice. Les linters propres à chaque langage restent la référence. ## Choisir la plus petite base de test JVM qui suffit au test Sélectionnez la plus petite base de test qui fournit le comportement requis. Les tests simples du runtime ou des utilitaires doivent utiliser la suite principale avec uniquement les aides communes de délai d’expiration, de fichier temporaire, de journalisation et d’erreur. Les tests du plan logique, de l’analyseur, de l’optimiseur ou du planificateur doivent employer une base de test des plans sans démarrer de session SQL. Les tests SQL ou de tables doivent utiliser la base de test des requêtes et intégrer explicitement un fournisseur de session comme mixin. Choisissez une session en processus pour les tests SQL ordinaires et un fournisseur reposant sur un entrepôt uniquement lorsque le comportement de cet entrepôt est requis. Ne supportez pas le coût d’un fixture plus large simplement parce que les tests voisins l’utilisent. ## Choisir la base de test Python adaptée aux tests locaux, distants et mixtes Les tests Python simples doivent utiliser la base standard de tests unitaires. Les tests au niveau du contexte peuvent créer un nouveau contexte d’exécution par test pour assurer l’isolation, ou en réutiliser un par classe pour gagner en rapidité. Les tests SQL et DataFrame doivent employer la base partagée de session classic, tandis que les tests d’extensions DataFrame peuvent ajouter une exécution en colonnes et des assertions spécialisées. Les tests du protocole distant exigent une décision distincte : utilisez un fixture mock limité aux plans quand aucun serveur n’est nécessaire, une session distante réutilisée pour le comportement distant réel, ou un fixture mixte classic et remote pour vérifier la parité. Traitez les utilitaires SQL, les assertions d’erreurs structurées et les aides d’égalité comme des mixins ou des aides autonomes plutôt que comme des bases de test, sauf s’ils créent le runtime requis. ## Compiler et tester seulement le module modifié, et demander avant la suite complète Les builds et les tests peuvent être coûteux. Si l’utilisateur a explicitement demandé les tests, exécutez-les. Sinon, avant de lancer une longue vérification de la suite complète, demandez si d’autres modifications sont prévues. Préférez l’outil de build incrémental le plus rapide du dépôt, compilez uniquement le module affecté et son code de test, puis exécutez une seule suite ou un cas nommé pendant les itérations. Gardez un shell de build incrémental ouvert lorsque cela réduit la durée des tests répétés du module. Pour les suites Python qui dépendent d’un backend compilé, construisez d’abord le profil de fonctionnalités requis, activez l’environnement virtuel choisi par l’utilisateur ou celui indiqué par défaut dans la documentation, et créez cet environnement uniquement s’il est absent. Utilisez les sélecteurs de suite et de cas du lanceur de tests du projet. ## Lister tous les échecs de CI avant d’en corriger un Énumérez toutes les vérifications ayant échoué pour le commit en revue avant d’étudier un échec particulier. Une vérification de résumé des tests réussie ou absente ne prouve pas que toute la CI est correcte ; les linters, les licences, les dépendances, les contrôles de compatibilité, la compilation et la génération de documentation peuvent échouer dans des tâches distinctes dépourvues d’annotations de test. Pour les tâches de test, utilisez les annotations d’échec afin d’obtenir la suite, le cas et le message. Pour les autres tâches, identifiez l’étape ayant échoué et lisez le journal ciblé de cette tâche. Évitez de télécharger de très grands journaux de tests fragmentés lorsque les annotations structurées contiennent déjà les preuves utiles. ## Vérifier si une pull request fermée a en fait été fusionnée Ne supposez pas qu’une revue marquée comme fermée a été rejetée. Certains projets réalisent les fusions au moyen d’outils personnalisés ; le service d’hébergement peut donc afficher une revue fusionnée avec succès comme fermée, sans horodatage natif de fusion. Utilisez l’aide du projet relative à l’état de fusion pour déterminer si la modification a été intégrée et quelles branches principales ou de maintenance la contiennent. Traitez les états ouvert, fusionné et fermé sans fusion comme des résultats distincts, et signalez l’absence d’authentification, un historique superficiel, des revues inconnues ou l’absence de remotes upstream comme des limites de l’environnement. ## Rédiger le titre et la description de la pull request selon le format du projet Respectez la convention de titre du projet pour les identifiants d’issue et les étiquettes de composant, y compris les exceptions documentées pour les modifications à l’état de brouillon, en cours, mineures ou triviales. Déduisez le titre de la différence. Lorsqu’un issue obligatoire manque, créez-le au moyen de l’aide du projet avec le composant exact et soit un type d’issue, soit une référence au parent ; affichez ensuite clairement l’issue créé et ses champs pour leur revue. Lisez le modèle de pull request du dépôt avant de rédiger la description et remplissez toutes les sections. Utilisez le nom complet du composant lorsque le gestionnaire d’issues l’exige, plutôt que l’étiquette de titre abrégée. ## Pousser seulement vers son fork et demander l’accord avant toute écriture externe N’exécutez jamais `push` vers le dépôt upstream faisant autorité ; exécutez `push` uniquement vers le fork du contributeur. N’appliquez ni `force-push` ni `amend` aux commits déjà présents sur le remote, sauf demande explicite de l’utilisateur. Si la branche distante a avancé, exécutez `fetch` et `rebase` avant `push`. Obtenez une approbation explicite avant toute écriture externe, telle que l’envoi de commits, la création d’une pull request ou d’un issue, ou la publication de commentaires. Utilisez le client authentifié pris en charge par le projet. S’il n’est pas disponible, préparez une URL de revue ou des instructions de transmission précises au lieu de contourner le flux de travail obligatoire. ## Utiliser le numéro de version de la branche qui publie le changement en premier Lorsque le code nécessite une annotation de version, une version de configuration ou une exclusion de compatibilité, utilisez la version de la branche dans laquelle la modification est publiée en premier et retirez le suffixe snapshot. Pour une revue basée sur une branche de maintenance, utilisez la version de cette branche. Pour une revue basée sur la branche principale, utilisez la version de la branche de publication la plus récente lorsque les modifications y sont normalement reportées par backport. Utilisez la version de la branche principale uniquement pour les travaux qui lui sont propres, comme une modification incompatible ou incompatible au niveau binaire, ou une mise à niveau de dépendance qui ne justifie pas un backport critique. Si le chemin de publication n’est pas clair, posez la question au lieu de le déduire de la seule branche principale. ## Lire la politique de sécurité du projet avant de signaler un problème de sécurité Avant de signaler un problème de sécurité, lisez la politique de sécurité et le modèle de menaces du dépôt. Confirmez le périmètre déclaré, les cas exclus et les cas documentés qui ne constituent pas des constats, afin d’évaluer le résultat d’un scanner au regard des garanties réelles du projet. Séparez l’enquête de sécurité du tri ordinaire des bogues, conservez les preuves et n’exposez ni identifiants d’accès ni données locales sensibles lors de la documentation d’un constat.