Quais são os prós e os contras da execução de testes de aplicativos durante vs. após a construção do docker?

Nosso dockerfile cria o ambiente do aplicativo (por exemplo, variáveis ​​env, instala bibliotecas com o apt-get etc.). Ele também extrai e copia o código do aplicativo python de seu repositório git.

No entanto, estamos discutindo se os testes de aplicativos (alguma unidade, alguma integração) devem ser colocados dentro de um RUNcomando docker (por exemplo RUN /bin/bash -c "source activate cool_env; pytest") ou após a compilação usando a pilha de IC (por exemplo, Jenkins, Openshift) para executar os testes no contêiner criado.

Quais são os prós e os contras de cada um?

Apoio a sugestão de J.Doe para arquivos Docker separados para cada um dos estágios de construção e teste. Essa abordagem também permite:

• execute novamente o estágio de teste por qualquer motivo (falhas intermitentes conhecidas, por exemplo) sem refazer o estágio de construção
• execute vários estágios de teste diferentes em paralelo usando a mesma compilação - por exemplo, em vez de executar um único estágio de teste longo composto de testes serializados, para um pipeline geral potencialmente significativo acelerando.

Se você executar tudo no mesmo contêiner ...

PRO: você resolveu o desafio do CasC para configurar o ambiente de teste em linha também

CON: você sente falta da parte da caixa preta, imagine que seu contêiner não aceitaria conexões externas. Ai!

Solução possível: eu iria, portanto, para um pipeline declarativo baseado em Docker em vários estágios: um ambiente Docker para cada estágio em que artefatos se conectam em cascata ao longo dele.