Environment Variable/Flag for Running GraalVM Tracing Agent

[matthenry87]

Describe the Enhancement

It would be great if I can deploy apps in their target environment with the native image tracing agent enabled, so that I can execute all code paths and capture all of the metadata needed for the subsequent native compilation. I know I can probably pass the arg myself, but I'm also looking for confirmation that the agent will be available in this JVM/JDK.

[dmikusa]

Can you provide a little extra detail here? What specific steps would you take to do this without buildpacks? Like if you were going to do a build in CI or on your laptop? Given that, I suspect we can give you some guidance on if that can be done with buildpacks and how. Thanks

[tjuchniewicz]

@dmikusa It's probably about building image that includes Tracing Agent . Currently to build such image we use custom Dockerfile but maybe there is a way to do it using BP parameters?

We use Buildpacks with Spring Boot plugin: https://docs.spring.io/spring-boot/maven-plugin/build-image.html#build-image. Not sure if this is correct project to ask this question.

[dmikusa]

Let me start by saying that the intent of Paketo buildpacks is to produce production-quality images. When you talk about including something like a tracing agent, that's not typically something you'd want in a production image.

To enable this for buildpacks, we'd have to ship an entirely different app image. Right now, the app image strips out all of the source code, JAR files, even the JVM and native image tools. These are not things you typically want in production.

The closest you could probably get is to do a non-native image build, but use one of the JVM vendors that provide native image tools, like GraalVM or Bellsoft (our Oracle buildpack doesn't presently do this). Include the BP_JVM_TYPE=jdk environment variable with the build. This will force it to put the JDK into the resulting image, which for these two vendors should also include native image tools. The build will produce a JAR file of your app and put that into the resulting app image as well, the contents of /workspace will be the exploded contents of your JAR file.

You could then start your app image but run a shell and once inside you should have access to the JDK, native image, and your JAR file so you could in theory run those tools. I say "in theory" because I haven't tried it myself. It's abusing the mantra of "production quality images" I mentioned above, but it might be good enough for what you're trying to do.

Having struggled with this exact problem tonight, I can certainly empathize that it's a pain to spin up a Linux VM or container to run the trace agent to update the metadata for the app. I'm just not sure we can make that process easier with buildpacks. The goal for buildpacks is just different.

That said, if you want to try the approach I outlined above and let me know how it goes, I'd be happy to talk more about it.