Como armazenar em cache recursos de terceiros em um pipeline de construção?

UMA pipeline de construçãogeralmente requer acesso a recursos de terceiros, além do código-fonte dos artefatos que ele pretende criar. Cada um desses recursos de terceiros introduz um fator de risco nas compilações, por exemplo:

• Os repositórios de distribuição estão temporariamente indisponíveis, portanto, a instalação dos pacotes de distribuição falha temporariamente.

• Os repositórios de distribuição estão permanentemente indisponíveis, iguais e piores que antes.

• Alguns pacotes de software livre do NPM param de existir, porque seu autor reivindicou essa retirada.

• Algum arquivo de origem ou pacote ad-hoc binário para uma ferramenta de terceiros não está mais disponível.

Essa lista pode ser estendida ad lib e, embora o estudo das várias razões que levem a que alguns recursos de terceiros desapareçam seja muito mais divertido, parece que em primeiro lugar tem uma conseqüência desastrosa para nós: o pipeline de construção está quebrado.

Qual é a melhor maneira de abordar os dois casos a seguir ao criar imagens de janela de encaixe :

1. Armazenando em cache arquivos baixados com um curl ou wget .
2. Armazenando em cache pacotes Debian.

Existem várias estratégias plausíveis que podem ser consideradas aqui. Por exemplo, usando um proxy e configurando o sistema de construção para rotear todas as suas solicitações por meio desse proxy. Uma segunda possibilidade barata seria agrupar chamadas curl para armazenar resultados em um cache local.

(Nesta pergunta, eu consideraria compartilhar o cache entre várias unidades do pipeline de construção como uma questão de importância secundária.)

Não estou muito familiarizado com o Docker particularmente, mas parece muito com os problemas que se obteria ao criar um aplicativo .NET normal ou um aplicativo java com a necessidade de armazenar suas dependências externas (DLL ou jar).

Para resolver isso, gosto bastante de artefatos. Dois dos mais populares são o Nexus do sonatype e o Artifactory do JFrog . Ambos oferecem uma versão gratuita de código-fonte aberto e ambos terão alguma maneira de armazenar pacotes personalizados ou usá-los como um depósito bruto. Existem outras opções por aí, acabei de listar essas duas porque já trabalhei com elas e sei que elas farão o que você precisa. Como bônus, você também poderá usá-los para gerenciar diretamente a imagem da janela de encaixe.

Também existem outros que vale a pena mencionar, você pode encontrar uma tabela de comparação para eles, obter uma melhor visão de seus recursos. (obrigado a Karl Harnagy pelo link)

Observe que algumas dessas opções podem exigir uma ou outra das versões pagas para o YMMV.

Alguns sistemas de integração contínua também suportam o conceito de artefatos (por experiência que Jenkins e a equipe da cidade fazem isso, outros também) que devem permitir que você obtenha resultados semelhantes diretamente.

Se nenhum deles fizer isso por você, você poderá procurar outras tecnologias ou criar suas próprias. Pessoalmente, gosto de alavancar tudo o que já possuo, reduzindo a manutenção necessária a longo prazo e facilitando a transferência de dinheiro quando chega a hora de procurar novos desafios em outros lugares.

Espero que isto ajude

Parece que o que você está procurando é menos sobre cache e mais sobre espelhamento. Como seus requisitos precisam lidar com pacotes permanentemente indisponíveis, você precisa persistir os pacotes em algo mais permanente que um cache. No passado, armazenamos pacotes em lojas persistentes baseadas na nuvem, como o S3. No entanto, não há nada para impedir que você configure um armazenamento de arquivos personalizado no servidor de construção.

Mais concretamente, provavelmente é mais fácil configurar um serviço de proxy que procure um recurso no seu armazenamento de arquivos (S3) e retorne o pacote, se for encontrado. Caso contrário, ele apenas solicitaria o recurso do upstream, preencheria seu armazenamento de arquivos e retornaria o pacote.