Expose CiUtils#isCi for usage outside of the extension

[clayburn]

See gradle/develocity-build-config-samples#636 (comment) for more.

This change would allow extensions that may include this extension in the classpath to reuse isCi for checks such background scan upload or remote scan store enabled.

[etiennestuder]

Did you think through all the consequences pros/cons of doing this? Exposing an API via or plugin, backward compatibility issues going forward, etc.?

[clayburn]

Did you think through all the consequences pros/cons of doing this? Exposing an API via or plugin, backward compatibility issues going forward, etc.?

The pro here is that we can allow extensions that include this extension in their classpath to reuse the exact same logic that we use in order to detect different CI environments. This best allows those extensions to have the same CI detection for background scan upload, remote cache store enabled, and CI/Local tags.

Without this change, we are asking anyone that uses our (in progress) sample conventions extension to re-implement this logic. They are likely to do so differently, in ways that may or may not matter. Some may even choose to duplicate our implementation for their convention extension. We likely have put more time into the CI detection logic than any of our implementers have.

When we consider the same case for the Gradle Plugin, the environment variable and system property checks become even more complex and prone to errors due to handling of configuration caching and its behavior in certain Gradle versions.

The cons here would be that we now have a public method as part of the API of this plugin, which means we would have to take care not to break users of that API. In this PR, we intentionally only expose the isCi() method, not the provider-specific checks, in order to reduce what gets exposed. We should add a javadoc as part of the PR (if we choose to do this) to document the public method. We could also consider moving it out of the quite generic com.gradle package into something more specific. Once it is released, we would be committed to the signature of this method not changing.

I'm open to more cons I may not be considering, but in my mind, by doing this, we limit the maintenance burden of the hopefully many implementers of our conventions samples in exchange for a small maintenance burden on us in keeping this API stable and backwards compatible. The method signature is quite simple so it seems that we could commit to these method signatures.

[clayburn]

After discussion, we'll point implementers of the convention extension to the relevant functionality in Common Custom User Data Maven Extension and let them just get the pieces that they need.