Nossas diversas ferramentas de track são implantadas como imagens Docker.
Cada ferramenta exige um Dockerfile, que especifica como a máquina é construída.
Ele deve ficar no diretório raiz do seu repositório e deve se chamar Dockerfile.
O Dockerfile deve criar a imagem mínima necessária para que a ferramenta funcione corretamente e com rapidez.
Nossa página de Boas Práticas tem várias dicas para ajudar você a alcançar esse objetivo.
Execução
Timeouts
O test runner recebe 100% de CPU e 3GB de memória por uma janela de 20 segundos por solução.
Depois de 20 segundos, o processo é interrompido e reporta um timeout com o código de erro 408.
Recomendamos fortemente seguir nosso documento de Boas Práticas de Desempenho para reduzir a chance de timeouts.
Stdout/stderr
Uma execução de ferramenta pode produzir no máximo um megabyte de stdout e stderr.
Se produzir mais, ela será encerrada com o código de erro 413.
O conteúdo de stdout e stderr de cada execução será armazenado em arquivos.
Você pode escrever um arquivo results.out no diretório de saída, contendo informações de depuração.
No momento, não é possível que os mantenedores vejam o conteúdo desses arquivos.
Resultados
O arquivo de resultados não pode ter mais de 500 kilobytes (incluindo stack traces etc).
Se o arquivo for maior que isso, a execução da ferramenta será encerrada com o código de erro 460.
Configuração
Cada solução recebe 100% dos recursos da máquina por uma janela de vinte segundos.
Depois de 20 segundos, o processo é interrompido e reportado como timeout.
Algumas ferramentas precisam de desvios (leves) da configuração padrão.
Nesse caso, elas são configuradas no arquivo tools.json no repositório do Tooling Invoker.
Rede
As ferramentas rodam sem acesso à internet. Existem duas configurações diferentes que você pode usar:
-
none. Isso desabilita o dispositivo de rede dentro do contêiner.
-
internal. Isso adiciona um dispositivo de rede dentro do contêiner, mas a rede não tem acesso a nada externo.
Linguagens diferentes se saem melhor ou pior com configurações diferentes (por exemplo, o Ruby é 2x mais rápido com none. O Elixir é 12x mais rápido com internal.
Você pode experimentar localmente usando a flag --network ao rodar seu docker. O --network none é suportado por padrão.
Para usar a rede interna, primeiro rode docker network create --internal internal para criar a rede e depois use --network internal ao rodar o contêiner.
Memória
As linguagens podem definir a memória máxima que precisam usar para rodar suas tarefas. Definir isso o mais baixo possível significa que podemos rodar mais tarefas em paralelo, mais rapidamente. Também significa que quem tentar abusar da memória não vai conseguir. Linguagens diferentes precisam de quantidades radicalmente diferentes de memória máxima. Fazer benchmark da execução de um docker run para estabelecer a memória máxima que ele usa é recomendado e agradecido.
A memória deve ser especificada usando o número com o sufixo b, k, m, g, para indicar bytes, kilobytes, megabytes ou gigabytes.
Rodando o Docker localmente
Você pode testar as configurações acima com 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/
Editando um Dockerfile
Todas as mudanças em Dockerfiles exigem uma revisão de PR da equipe @exercism/maintainers-admin, para evitar a introdução de vulnerabilidades de segurança.
