This message was deleted.

Are you saying that "clean" brings the env. vars back?

Stopping the daemons via

./gradlew --stop

and then re-running

clean build

of which will start up a new daemon per the output message. For example:

❯ ./gradlew --stop
Stopping Daemon(s)
1 Daemon stopped
❯ ./gradlew clean build -x test
Starting a Gradle Daemon, 4 stopped Daemons could not be reused, use --status for details

Really hard to say from the information you provided. Gradle spawns several new processes potentially. Test worker processes to run tests, worker processes for worker api work items with process isolation, Kotlin compile daemon, Gradle daemon, ... But none should "loose" access to environment variables. Btw. the trained behaviour to always also run

clean

is usually caused by Maven behaving bad, mixing outputs and having stale files and so on. With Gradle you should usually not always run

clean

with your build, as all that you cause with it is making some of the most useful features like up-to-date checks void. With Gradle if you really need to call

clean

to get a good build result, that is usually more a sign of some bug in the build scripts or plugins of the current project.

For the record, my best working theory on the root of the issue I was encountering was JDK 11, older version of Gradle, and the mac M1 chip not playing nicely together. Once I upgraded gradle to 7.4.1 and resolved some plugin changes, things seem to be working without issue. 👍