Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GradleEnterprise -> Develocity #27

Merged
merged 7 commits into from
May 9, 2024
Merged

Conversation

blindpirate
Copy link
Contributor

@blindpirate blindpirate commented Apr 23, 2024

Fixes #26

Upgrades to develocity plugin and eliminate all deprecated API usages. Tests are updated accordingly.

build.gradle.kts Outdated Show resolved Hide resolved
build.gradle.kts Outdated Show resolved Hide resolved
@@ -45,9 +45,9 @@ extensions.configure<ExtraPropertiesExtension>("ext") {
gradlePlugin {
plugins.create("conventionsPlugin") {
id = "io.github.gradle.gradle-enterprise-conventions-plugin"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we remove gradle-enterprise from the plugin ID here?

implementationClass = "com.gradle.enterprise.conventions.GradleEnterpriseConventionsPlugin"
displayName = "Gradle Enterprise Conventions Plugin"
description = "Gradle Enterprise Conventions Plugin"
implementationClass = "com.gradle.enterprise.conventions.DevelocityConventionsPlugin"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we move the relevant classes to the io.github.gradle package and remove the enterprise part while we are at it?

We should also consider JEP 261 and make an effort to avoid the package name collision risk with develocity itself

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intentionally keep all "interface" of this plugin unchanged (like package name, implementation class name, etc.). Let's do that in a separate PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how a separate PR is better than separate commits in this PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renaming the implementation class means moving all files to another directory, which in some cases confuses GitHub web UI to display the diffs - showing all files as "new". That's why I want to do the moving in a separate PR - to make this PR show "diffs".

public class GradleEnterpriseConventions {
private static final Logger LOGGER = Logging.getLogger(GradleEnterpriseConventions.class);
public class DevelocityConventions {
private static final Logger LOGGER = Logging.getLogger(DevelocityConventions.class);
private static final String DEFAULT_GRADLE_ENTERPRISE_SERVER = "https://ge.gradle.org";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DEFAULT_GRADLE_ENTERPRISE_SERVER => DEFAULT_DEVELOCITY_SERVER?

public class GradleEnterpriseConventions {
private static final Logger LOGGER = Logging.getLogger(GradleEnterpriseConventions.class);
public class DevelocityConventions {
private static final Logger LOGGER = Logging.getLogger(DevelocityConventions.class);
private static final String DEFAULT_GRADLE_ENTERPRISE_SERVER = "https://ge.gradle.org";
private static final String AGREE_PUBLIC_BUILD_SCAN_TERM_OF_SERVICE = "agreePublicBuildScanTermOfService";
private static final String GRADLE_ENTERPRISE_URL_PROPERTY_NAME = "gradle.enterprise.url";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also add a (prioritized) lookup for gradle.develocity.url or develocity.url?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done here: 56329e0

displayName = "Gradle Enterprise Conventions Plugin"
description = "Gradle Enterprise Conventions Plugin"
implementationClass = "com.gradle.enterprise.conventions.DevelocityConventionsPlugin"
displayName = "Develocity Conventions Plugin"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this published to the plugin portal? Then we should make clear that this is a Develocity conventions plugin for the Gradle Github organization.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's fix this in another PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, what is the benefit of a separate PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing the implementation class means moving all files to another directory. I don't like to mix them as that would mess up file diffs.

@@ -1,17 +1,15 @@
package com.gradle.enterprise.conventions;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 I don't think the package com.gradle.enterprise is great. I don't think it should be com.gradle at all since it is for the open source parts of Gradle. Let's rename those things in a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let's do this in separate PR. This PR only switch from gradle enterprise API to develocity API.

public static final PublishingConfigurationAction PUBLISH_IF_AUTHENTICATED = new PublishingConfigurationAction("publishWhenAuthenticated") {
@Override
public void execute(BuildScanPublishingConfiguration publishing) {
publishing.onlyIf(BuildScanPublishingConfiguration.PublishingContext::isAuthenticated);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 Could we be a little bit better here now? I'd say we publish if

  • We are authenticated
  • or someone requests --scan via the command line.

WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would mean changing the behavior of this param:

String strategy = conventions.getSystemProperty("publishStrategy", "publishAlways");

We could do that but I'd keep this PR only deal with renaming.

import java.io.IOException;
import java.util.function.BiFunction;

abstract class ProxyProperty<T> implements Property<T> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 Why do we need this for testing? Can we get rid of it now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plz see the answer in my next comment. It's used to match the develocity plugin interface and adapt to serialization/deserialization.


import javax.annotation.Nullable;

public class DevelocityConfigurationForTest implements DevelocityConfiguration {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 Can't we use a regular mocking framework like Mockito or Spock?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The integration test we do right now is:

  1. Create a "fake" develocity plugin with same id/implementation class.
  2. Run the Gradle build with the fake develocity plugin via TestKit. The fake develocity plugin accepts configuration actions from the build and stores the configurations in this DevelocityConfigurationForTest class.
  3. At the end of Gradle build, the configurations are written to a JSON file.
  4. In the integration test, the JSON file is deserialized to verify the configurations are correct.

So in the integration test, we need to pass information between the "outside" Gradle build (the integration test JVM) and the "inside" Gradle build (the build running with fake develocity plugin) - we can't create a mockito mock in JVM1 and use it in JVM2. Plus, we need to serialize/deserialize the configuration, this DevelocityConfigurationForTest is also used as data class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a better way to test this? And even if we use a fake develocity plugin, why can't the fake develocity plugin use real Property instances instead of this strange ProxyProperty?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PLMK if you have better idea, but in this PR let's keep this imperfect way. I pushed a new commit to use a real Property.

@blindpirate blindpirate requested review from cobexer and wolfs May 8, 2024 01:32
@blindpirate blindpirate merged commit ffcc47f into master May 9, 2024
3 checks passed
@blindpirate blindpirate deleted the bz/fix-deprecated-api branch May 9, 2024 06:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove deprecated API usage
3 participants