Support CLI-option for "environment" in Buildpacks configuration

[ThomasVitale]

Context

The Spring Boot plugins for Gradle and Maven allows configuring the Buildpacks task via properties in the build.gradle or pom.xml files. Some of the properties can be specified via convenient CLI options, which are especially useful when automating certain workflows such as in a CI environment or when automating a local development workflow on Kubernetes.

Feature Suggestion

It would be extremely useful if it was possible to pass environment variables to Buildpacks via CLI options. For example:

./gradlew bootBuildImage --environment BP_LIVE_RELOAD_ENABLED="true"

When multiple environment variables:

./gradlew bootBuildImage --environment BP_LIVE_RELOAD_ENABLED="true" --environment BPL_JAVA_NMT_ENABLED="false"

Why

Two main reasons why I'm suggesting this feature:

• The Paketo Buildpacks offer incredible flexibility and settings for production that can be toggled on/off via environment variables. It would be useful to have the possibility to pass environment variables in a CI pipeline to configure features that are not needed by default in a local environment.
• One of the features offered by Paketo Buildpacks is support for live reload, which needs to be activated via an environment variable. It works well paired with Spring Boot DevTools and a tool like Skaffold or Tilt, but it would be great if the extra environment variable could be configured via CLI only in the Skaffold/Tilt configuration rather than in the build.gradle/pom.xml file.

Alternatives Considered

The alternative I considered would be to introduce some profiles/feature flags in the pom.xml/build.gradle and add the configuration needed only in CI or only for local development behind those. However, this has a huge impact on the developer experience and maintenance cost. Furthermore, for the CI use case, it means that it's not possible to centralise the configuration in a common pipeline since changes are needed in each project's build.gradle or pom.xml file (unless perhaps more complex settings are introduced, such as init.gradle scripts or settings.xml extra options, but those would not be viable alternatives for all the use cases).

Contributions

If you think this feature makes sense for Spring Boot, I volunteer my time to help implement it.

[wilkinsona]

Thanks for the suggestion. This seems like a nice addition alongside the existing @Options on BootBuildImage.

The existing environment property is a Map:

spring-boot/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin/src/main/java/org/springframework/boot/gradle/tasks/bundling/BootBuildImage.java

Lines 155 to 160 in 4531d9e

	/**
	* Returns the environment that will be used when building the image.
	* @return the environment
	*/
	@Input
	public abstract MapProperty<String, String> getEnvironment();

@Option does not support maps and we would want to change the type of the environment property to accommodate this feature. It may be possible to introduce a new @Internal ListProperty<String> for the environment variables contributed from the command line and to map these into the existing environment property. Some experimentation in this and similar areas that explores what may be possible would be most welcome.