GitLab Runner: encontre as configurações de proxy para a etapa do job que falhou
O controle do Runner, a obtenção da imagem, a obtenção do repositório e os downloads dentro do job podem vir de processos diferentes.
| Primeira falha | Entrada a inspecionar |
|---|---|
| O Runner contata o GitLab | Ambiente do serviço Runner |
| Baixar a imagem do job | Serviço de daemon/download do Docker |
| Obter o repositório | Ambiente real do cliente/auxiliar Git |
| Download do comando do job | O contêiner e as configurações de cliente próprias dessa ferramenta |
Uma variável de job chega tarde demais para um download de imagem que já é necessário para criar o contêiner. Uma conexão de controle do Runner bem-sucedida também não consegue estabelecer a acessibilidade de um job isolado.
Para 127.0.0.1:3128, localize o listener: o loopback do contêiner do job não é o host do Runner. Conceda acesso a um auxiliar no host apenas às redes de job pretendidas e gerencie a conta upstream dele de forma deliberada.
Aplique a interface compatível do Runner/executor implantado e, depois, as opções versionadas do downloader real. Mantenha a etapa, o processo solicitante e o endpoint tentado em diagnósticos redigidos em vez de colocar suposições específicas da conta em wrappers compartilhados.