./gradlew test -Drecreate=true

[iamdanfox]

Before this PR

A number of our repos use the ./gradlew test -Drecreate=true pattern, but I recently found (on our circle-templates repo) that we've been doing it wrong the entire time. Specifically, the task short-circuits and doesn't run when there are no code changes, even though the behaviour should be different when -Drecreate=true is passed in.

After this PR

==COMMIT_MSG==
For repos that use snapshot-style testing, ./gradlew test -Drecreate=true will ensure the "recreate" system property is passed through to Java correctly.
==COMMIT_MSG==

Possible downsides?

[changelog-app]

Generate changelog in changelog/@unreleased

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

For repos that use snapshot-style testing, ./gradlew test -Drecreate=true will ensure the "recreate" system property is passed through to Java correctly.

Check the box to generate changelog(s)

• Generate changelog entry

[carterkozak]

Should be be defensive and disable caching when shouldRecreate=true?

[carterkozak]

We may want to require/force boolean values here, possibly Boolean.getBoolean("recreate") and use the string value for the sysprop+input?

[ferozco]

Its seems slightly out of scope for baseline to handle this convention and the upside for adding this is pretty low since in the worst case things will fail at CI time

[dansanduleac]

The reason to put this in a common place is that we keep copy pasting a chunk of gradle to help us do this, and we'd rather do away with the duplication.

[iamdanfox]

@ferozco I mean we have quite a diverse chunk of functionality in baseline already, stuff to give us reproducibility, compilation fixes, circleci.

While it's a bit weird, I think it's in line with the overall goal of trying to minimise floating blobs of identical gradle across projects (especially when you find a bug in one of them!).

[ferozco]

👍