mhoennigandClaude Opus 5
5305362c01
werkator/branch build succeeded after 08:48
Three changes to the pipeline itself, none of them to what is verified. The CI script called Gradle twice, paying a second start-up to run the two acceptance tasks. Both already depend on test and bootJar, so one invocation runs the suite exactly once and the second start-up is gone. The frontend tests move after it; they need the Node installation that the production frontend build leaves behind either way. The build cache is on. Werkator keeps GRADLE_USER_HOME between runs, so a trunk build whose sources a branch build already compiled compiles almost nothing. The test task is excluded on purpose: a cached pass is an honest statement about identical inputs, but a build that deploys should run its tests. The configuration cache is on. Two actions had to stop reaching back into the build script, and generatePrototypeJooq and generateJooq now delete their output directories through plain file operations. The seven production scenarios run two at a time. Each owns its temporary directory, its ephemeral port and its report file, so they cannot observe one another: 216 s sequential, 167 s in pairs. Two, not four, because every scenario starts its own application JVM. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
11 lines
610 B
Properties
11 lines
610 B
Properties
org.gradle.jvmargs=-Xmx512m -XX:MaxMetaspaceSize=384m
|
|
org.gradle.workers.max=2
|
|
kotlin.compiler.execution.strategy=in-process
|
|
# Reuse compilation results across builds of the same sources. Werkator keeps GRADLE_USER_HOME
|
|
# between runs, so the trunk build after a green branch build compiles almost nothing. The test
|
|
# task is excluded in build.gradle.kts: a build that deploys must run its tests.
|
|
org.gradle.caching=true
|
|
# Skip re-configuring an unchanged build. Worth about four seconds per invocation, and it keeps
|
|
# the local pipeline identical to the one Werkator runs.
|
|
org.gradle.configuration-cache=true
|