I'm experiencing a behavior I don't understand. Is this a bug or am I on the wrong track?
When building a container image with the Spring Boot mvn plugin, I can't contribute custom buildpacks, in a way I would expect it. (Also as suggested by Buildpack: customisation needed to add opentelemetry)
Does the buildpack config overrule all BP_... flags and just contribute all the packs listed?
Is this maybe a bug in the jprofiler buildpack, where the BPL_JPROFILER_ENABLED flag evaluation is faulty?
Example repo and steps: https://github.com/jakesmolka/spring-boot-buildpack-jprofiler
Run mvn spring-boot:build-image -DskipTests
Run docker run -e BPL_JPROFILER_ENABLED=true docker.io/library/spring-boot-buildpack-jprofiler:0.0.1-SNAPSHOT
Jprofiler gets started.
Run docker run -e BPL_JPROFILER_ENABLED=false docker.io/library/spring-boot-buildpack-jprofiler:0.0.1-SNAPSHOT
Jprofiler gets started as well.
Run docker run docker.io/library/spring-boot-buildpack-jprofiler:0.0.1-SNAPSHOT
Jprofiler gets not started.
Remove <buildpacks> section from pom and rebuild the image: jprofiler support is not contributed to the image.
Re-add the section.
Set <BP_JPROFILER_ENABLED> env to false and rebuild the image. The output shows no difference, jprofiler gets contributed regardless.
Cross-checking behavior with BPL_DEBUG_ENABLED:
Run docker run -e BPL_DEBUG_ENABLED=false docker.io/library/spring-boot-buildpack-jprofiler:0.0.1-SNAPSHOT
Debug is not enabled.
Run docker run -e BPL_DEBUG_ENABLED=true docker.io/library/spring-boot-buildpack-jprofiler:0.0.1-SNAPSHOT
Debug is enabled.
So BPL_DEBUG_ENABLED works as expected.
Does the buildpack config overrule all BP_... flags and just contribute all the packs listed?
When you set the buildpack list with Spring Boot buildpack tools or pack cli, two things change:
Your list now becomes the complete and only set of buildpacks that will run. If it's not in your list, those buildpacks don't run. Thus, when you set a custom buildpack list, it needs to be a complete list of all the buildpacks needed to run your app. Any easy way to find this list, is to run once without, copy the list of buildpacks that run and adjust from there.
All buildpacks specified are required. There are no optional buildpacks when you specify the list. This means that if one of the buildpacks you add fails detection then the build will fail. All buildpacks are required. If you don't need the buildpack, remove it from the list.
Aside from that, it should not impact what env variables are set or how buildpack interpret those env variables.
Is this maybe a bug in the jprofiler buildpack, where the BPL_JPROFILER_ENABLED flag evaluation is faulty?
The Paketo team uses prefixes on the front of environment variables to signal their intent.
BP_ environment variables are those that impact build timeBPL_ environment variables are those that impact launch time (i.e. when your app actually starts)BPI_ environment variables are those that are intended to be internal and not user manipulated (i.e. buildpack sets these to pass data from build to launch)BPE_ environment variables are specific to the environment variables buildpack.In this case, you're asking about a BPL_ prefixed env variable, so it would not impact anything that happens at build time, but it should impact JProfiler behavior at launch time. This one in particular is there so that you can turn on/off the JProfiler agent at launch time without needing to rebuild your container.
If you want to tell the JProfiler buildpack at build time to not include itself, then you want to set BP_JPROFILER_ENABLED=false however see 2.) from the comment above because this is going to cause JProfiler buildpack to fail detection and thus your build is going to fail. If you don't want JProfiler included in the image at all, simply remove it from your list of buildpacks.
That is the intended behavior at least. There are some buildpacks, we're working to clean up, which do not actually look at the state of boolean variables. They simply look at the presence of the variable. Thus if BPL_JPROFILER_ENABLED is set it treats it as true if it's unset then it treats it as false, not looking at the value itself.
I took a quick look and this buildpack and the setting you're mentioning is one of those. So yes, it's buggy and not behaving how it should. I created a bug for this: https://github.com/paketo-buildpacks/jprofiler/issues/120. Contributions welcome.