De onde o Gradle obtém suas configurações de proxy

Acompanhe as propriedades de proxy da JVM do Gradle, as configurações da pasta pessoal do usuário e o ambiente do cliente em vez de presumir que o daemon sempre ignora variáveis novas.

Um build do Gradle iniciado por uma IDE pode usar uma configuração diferente da do mesmo projeto iniciado em um terminal. Antes de culpar um processo de proxy antigo, compare a pasta pessoal do Gradle, a JVM e as propriedades de proxy usadas em cada inicialização.

O Gradle documenta propriedades de proxy da JVM

Para rotas HTTP e HTTPS, um arquivo de propriedades pode conter:

systemProp.http.proxyHost=203.0.113.10
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=203.0.113.10
systemProp.https.proxyPort=8080
systemProp.http.nonProxyHosts=localhost|*.example.internal

Use o endpoint atribuído; para rotas permitidas a repositórios públicos, a lista de proxies HTTP fornece pares candidatos de host e porta. A propriedade de bypass de HTTPS também é http.nonProxyHosts; inventar https.nonProxyHosts não é a correção documentada. As propriedades de host contêm um endereço, não uma URL de proxy completa.

Exportar HTTP_PROXY em um shell, por si só, não prova que este cliente JVM o usa como sua política de proxy. Verifique as propriedades que a aplicação oferece.

O daemon recebe informações do build

A documentação atual do Gradle diz que o cliente envia ao daemon informações do build, incluindo variáveis de ambiente. Portanto, a explicação geral “o daemon nunca recebe novas variáveis de ambiente” é imprecisa.

Algumas propriedades de inicialização da JVM, incluindo propriedades do trust store, são imutáveis para uma JVM em execução. Uma configuração de Java home ou de inicialização do trust store alterada pode, portanto, ser relevante mesmo quando os valores normais do ambiente de build são repassados.

Compare as duas inicializações

Verifique qual distribuição do Gradle e qual runtime Java a IDE seleciona. Verifique se ela usa o mesmo GRADLE_USER_HOME e as mesmas propriedades do usuário que o terminal. Uma entrada de proxy na configuração de um usuário não mostra o que outro contexto carregou.

Se um requisito de inicialização alterado precisar de outro daemon, use os controles documentados do daemon para a versão do Gradle em questão. Não trate a parada dos daemons como substituta para encontrar uma propriedade incorreta ou um arquivo de configuração ausente.

Por fim, identifique a solicitação que falhou. Downloads do Wrapper, resolução de dependências do build e solicitações feitas por processos bifurcados da aplicação ou de testes não são automaticamente um único contexto de rede. Verifique o processo que faz a solicitação antes de esperar que uma propriedade do Gradle o controle.

Artigos relacionados