Option to enable/disable injection logging is added

[erichaagdev]

Adds the property develocity.injection.logging-enabled to enable or disable all log output from the injection script. Logging is enabled by default if not specified.

This provides a mechanism for consumers to disable only injection logging without affecting the rest of the logging done by the build.

For maintainers, this requires all current and future logging to be done through the new log(Gradle, Logger, LogLevel, String) function.

[erichaagdev]

I moved all the outputMisses.../outputContains... checks and DvInjectionTestConfig helper class to the base init script so all test classes that subclass this class can access them. Some of are only related to injection, so you might consider this a code smell. However, I would also consider statically referencing one of these functions from TestBuildScanCapture to also be a code smell.

develocity-ci-injection/src/test/groovy/com/gradle/TestBuildScanCapture.groovy

Line 29 in 1194704

def config = TestDevelocityInjection.createTestConfig(mockScansServer.address, testDvPlugin.version)

I saw this as the simplest solution to share these checks that didn't require splitting the checks up or duplicating them. I'm open to other ideas.

[bigdaz]

@erichaagdev I agree with the idea of making the injection script less "noisy", but what was the trigger to make this change now? What clients are expected to disable logging?

I wonder if it wouldn't be better to just make the logging less intrusive in general:

• By default, log at INFO level instead of LIFECYCLE or QUIET.
• Leave the current WARNING log message, since this indicates a misconfiguration.
• In testing, run builds with --info to ensure we can pick up the required log messages.

I would prefer to avoid adding a new flag to specifically disable injection logging, unless we really need it.

[erichaagdev]

@bigdaz My apologies for not including this in the original description. My intention for this was to be used primarily for the BVS where the user is usually running these from the terminal and the additional messages cause some (minor) noise. In most cases, like the CI plugins, this isn't really an issue.

I'm fine going with the approach you suggested. The reason I went this path was so the logging could be enabled by default and not impact the CI plugins, for which this additional logging could be useful.

[bigdaz]

I'm not sure the additional logging is all that useful for CI integrations. The messages may be helpful during initial setup and when debugging issues, but I don't feel that they add any value during "normal" operation.

If possible, I will likely suppress the log messages by default for setup-gradle.

[erichaagdev]

Sounds good. In that case, I'll close this PR and create a new one since there will be little reuse of what I have here to implement your suggestion.