ci: default Kotlin gradle-args to --parallel --build-cache [NOJIRA]

[tobias0106]

Why

service-wallet#4478 sped up its Sonar step by overriding gradle-args in the caller: --parallel --build-cache instead of the shared default --no-daemon --parallel. Dropping --no-daemon lets the test/sonar/coverage steps share one warm Gradle daemon, and --build-cache lets later invocations reuse outputs.

This promotes that optimization to the shared Kotlin workflows so every Kotlin service gets it as the default, instead of each repo overriding per-caller.

What

Change the gradle-args input default from --no-daemon --parallel to --parallel --build-cache in all reusable Kotlin/Gradle workflows:

• pull-request-kotlin.yml
• sonar-cloud.yml
• code-coverage-kotlin.yml
• component-test-kotlin.yml
• deploy-kotlin.yml
• deploy-kotlin-v2.yml

Input-only change — callers that already pass an explicit gradle-args are unaffected.

Risk / tradeoffs

• Blast radius: all Kotlin services that rely on the default. The daemon now persists within/between jobs on the runner. On the standard large/blacksmith runners this is the intended setup.
• Any service can revert to the old behaviour by passing gradle-args: "--no-daemon --parallel" explicitly.

Draft — open for review before un-drafting.

🤖 Generated with Claude Code

[JesperTerkelsen]

Be careful making this default across all projects - this can break stuff if tests are not supporting parallel runs - perhaps introduce a parameter instead ?

[morten-andersen]

I like it - but a scary change - we risk blocking a lot of kotlin services - and quite a few people are out for vacation in many teams

[tobias0106]

Be careful making this default across all projects - this can break stuff if tests are not supporting parallel runs - perhaps introduce a parameter instead ?

Fair point. Also a risky PR.
Lets migrate one project at the time with the parameters.

[tobias0106]

I like it - but a scary change - we risk blocking a lot of kotlin services - and quite a few people are out for vacation in many teams

Would just be cool to streamline things across all Kotlin services, but I agree it's not worth the risk. Appreciate the feedback! :praise