This message was deleted.
# community-support
s
This message was deleted.
a
c
@Adam thanks, at least now I know that my plugin is properly applying. I assumed (because I'm a lazy reader), that debug set that as something like a log level... because that's the intuitive
v
What I usually do in a functional test base class is
Copy code
if (ManagementFactory.runtimeMXBean.inputArguments.any { it.startsWith('-agentlib:jdwp=') }) {
    runner.withDebug(true)
}
This way when I use
--debug-jvm
or press "Debug" in the IDE,
withDebug(true)
is automatically used and it just works. 🙂
👍 1
c
yeah, I was thinking of doing that, or, like, just leaving it on
the actual IO this does is probably more expensive
v
What IO? It just checks some in-JVM state, doesn't it?
c
oh, in my case I have to create a git repo
and run some commits, I don't know what overhead having
withDebug
set is, but I'm moderately confident that hard drive access is more expensive
v
Ah, not I got what you mean
withDebug
just makes the tests be run in-process instead of forked so that when debugging the test execution you can debug into the Gradle build
c
however, looks like
withDebug
doesn't work with configuration cache, so...
right, that feels like a good default...
not sure why the choice was to make it not
anyways, now I'm whinging
so, back to me STFU
v
Probable because it is more production like to have the test run forked and not in-process?
c
🤷
v
Also, if you want to set environment variables this is incompatible with
withDebug