Spring Boot Image Builds: Configure the Paketo Builder’s Proxy

A build tool can resolve its dependencies successfully while a Paketo buildpack cannot download a runtime. The buildpack runs inside the builder container and needs its own proxy input.

Gradle’s bootBuildImage task

In a Groovy build.gradle using Spring Boot’s existing bootBuildImage task:

tasks.named("bootBuildImage") {
    environment["HTTP_PROXY"] = "http://proxy.example:8080"
    environment["HTTPS_PROXY"] = "http://proxy.example:8080"
}

The Maven plugin uses image.env

For spring-boot:build-image, place these values under image.env in the existing Spring Boot Maven plugin configuration:

<configuration>
  <image>
    <env>
      <HTTP_PROXY>http://proxy.example:8080</HTTP_PROXY>
      <HTTPS_PROXY>http://proxy.example:8080</HTTPS_PROXY>
    </env>
  </image>
</configuration>

Gradle’s task environment and Maven’s image.env both supply values to the builder. Both names can identify the same ordinary HTTP intermediary, including for HTTPS artifact URLs. For public artifact downloads allowed through public proxies, the HTTP proxy list supplies candidates for these builder values.

This setting is independent of Gradle’s systemProp.http.proxyHost properties. Those belong to the JVM and do not automatically configure another process in the builder.

The Docker daemon must first obtain the required builder and run images. A registry failure at that earlier stage needs the daemon’s route and registry configuration, rather than a variable supplied to a buildpack that has not started.

Use a proxy endpoint reachable from the builder container. Its loopback address identifies that container, not necessarily the developer’s workstation.

Keep the final application’s runtime environment deliberate too. Build-time access and the route used when the application later runs are separate configuration decisions.