Nuestras distintas herramientas de track se despliegan como imágenes de Docker.
Cada herramienta necesita un Dockerfile, que especifica cómo se construye la máquina.
Debe estar en el directorio raíz de tu repositorio y llamarse Dockerfile.
El Dockerfile debe crear la imagen mínima necesaria para que la herramienta funcione correctamente y con rapidez.
Nuestra página de Buenas prácticas tiene un montón de consejos que te ayudarán a lograr este objetivo.
Ejecución
Tiempos de espera
El ejecutor de pruebas dispone del 100 % de la CPU y de 3 GB de memoria durante una ventana de 20 segundos por solución.
Transcurridos los 20 segundos, el proceso se detiene y notifica un tiempo de espera agotado con un código de error 408.
Te recomendamos encarecidamente que sigas nuestro documento de Buenas prácticas de rendimiento para reducir la probabilidad de que se agote el tiempo de espera.
Stdout/stderr
Una ejecución de las herramientas puede producir como máximo un megabyte de stdout y stderr.
Si produce más, se eliminará con un código de error 413.
El contenido de stdout y stderr de cada ejecución se guardará en archivos.
Puedes escribir un archivo results.out en el directorio de salida, que contiene información de depuración.
Ahora mismo, los mantenedores no pueden ver el contenido de estos archivos.
Resultados
El archivo de resultados no puede ser mayor de 500 kilobytes (incluidas las trazas de pila, etc.).
Si el archivo es mayor, la ejecución de las herramientas se eliminará con un código de error 460.
Configuración
Cada solución dispone del 100 % de los recursos de la máquina durante una ventana de veinte segundos.
Transcurridos los 20 segundos, el proceso se detiene y se notifica como un tiempo de espera agotado.
Algunas herramientas requieren desviaciones (ligeras) de la configuración predeterminada.
Si es así, se configuran en el archivo tools.json del repositorio Tooling Invoker.
Red
Las herramientas se ejecutan sin acceso a internet. Hay dos configuraciones diferentes que puedes usar:
-
none. Desactiva el dispositivo de red dentro del contenedor.
-
internal. Añade un dispositivo de red dentro del contenedor, pero la red no tiene acceso a nada externo.
Los distintos lenguajes rinden mejor o peor con configuraciones diferentes (p. ej., Ruby es 2x más rápido con none. Elixir es 12x más rápido con internal.
Puedes experimentar en local usando el flag --network al ejecutar tu docker. --network none es compatible de forma predeterminada.
Para usar la red interna, ejecuta primero docker network create --internal internal para crear la red y, después, usa --network internal al ejecutar el contenedor.
Memoria
Los lenguajes pueden establecer la memoria máxima que necesitan usar para ejecutar sus tareas. Establecerla lo más baja posible significa que podemos ejecutar más tareas en paralelo y con mayor rapidez. También significa que quienes intenten abusar de la memoria no podrán salirse con la suya. Los distintos lenguajes necesitan cantidades máximas de memoria drásticamente distintas. Se recomienda y agradece medir la ejecución de un docker run para establecer la memoria máxima que utiliza.
La memoria debe especificarse usando el número con el sufijo b, k, m o g, para indicar bytes, kilobytes, megabytes o gigabytes.
Ejecutar Docker en local
Puedes probar la configuración anterior con este comando:
docker container run -v /path/to/job:/mnt/exercism-iteration --network none -m 1GB exercism/ruby-test-runner lasagna /mnt/exercism-iteration/ /mnt/exercism-iteration/
Editar un Dockerfile
Todos los cambios en los Dockerfiles requieren una revisión de PR por parte del equipo @exercism/maintainers-admin, para evitar la introducción de vulnerabilidades de seguridad.
