SLCORE-1815 Feature/slcore 1647 gessie integration #1568

Krosovok · 2025-11-07T07:44:30Z

SLCORE-1815

sonarqube-next · 2025-11-07T15:03:33Z

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
91.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

…gration

nquinquenel

Looks mostly good, few comments

nquinquenel · 2025-11-18T18:06:58Z

...elemetry/src/main/java/org/sonarsource/sonarlint/core/telemetry/gessie/GessieHttpClient.java

+      LOG.info("Sending Gessie payload.");
+      LOG.info(json);


Can probably merge the two log

nquinquenel · 2025-11-18T18:10:13Z

medium-tests/src/test/java/mediumtest/gessie/GessieIntegrationMediumTests.java

+  static WireMockExtension gessieEndpointMock = WireMockExtension.newInstance()
+    .options(wireMockConfig().dynamicPort())
+    .build();


Ideally we should use the dev or staging endpoint and not a mock

I think at this point it would make more sense to write full end-to-end tests when we will have some more relevant events to send. And also since their side still has validation problems it would just be a failing test.

nquinquenel · 2025-11-18T18:11:20Z

medium-tests/src/test/java/mediumtest/gessie/GessieIntegrationMediumTests.java

+    var fileContent = getTestJson("GessieRequest");
+    await().untilAsserted(() -> gessieEndpointMock.verify(postRequestedFor(urlEqualTo(IDE_ENDPOINT))
+      .withHeader("x-api-key", new EqualToPattern("value"))
+      .withRequestBody(equalToJson(fileContent))));


Could be worth checking the actual request body with a fully formatted JSON, to be sure of what we assess

I am not sure I understand you correctly. Do you mean to compare strictly instead of equalToJson? Wouldn't that just make the test fail when we don't actually care? I don't want it to fail when we changed field order or something.

nquinquenel · 2025-11-18T18:13:15Z

backend/telemetry/src/test/resources/response/gessie/GessieHttpClientTest/InvalidRequest.json

+{
+  "metadata": null,
+  "event_payload": null
+}


Do we need a file for this?

Yes, it's still test data, not the test code. And I expect to make more of these as we will develop this feature further. It wouldn't make sense to do just some of them differently.

nquinquenel · 2025-11-18T18:16:02Z

...d/telemetry/src/main/java/org/sonarsource/sonarlint/core/telemetry/gessie/GessieService.java

+  @PostConstruct
+  public void onStartup() {
+    if (isGessieFeatureEnabled && userSetting.isTelemetryEnabledByUser()) {
+      client.postEvent(new GessieEvent(
+        new GessieMetadata(UUID.randomUUID(),
+          new GessieMetadata.GessieSource(SonarLintDomain.fromProductKey(telemetryConstantAttributes.getProductKey())),
+          "Analytics.Editor.PluginActivated",
+          Long.toString(Instant.now().toEpochMilli()),
+          "0"),
+        new MessagePayload("Gessie integration test event", "slcore_start")
+      ));
+    }
+  }


I think we need a proper method that takes a GessieEvent and that handles the sending (postEvent), to have separation of concerns. Later when we have multiple event to send, they all go through this upload method.

I am not sure I understand what you mean. We already have a separate method in client: postEvent. I see here 3 things done:

Checking if gessie is on (if content)

building an event

sending it via one line client.postEvent(<event>)

What exactly you want to move? 1 & 3 into a separate method?

nquinquenel · 2025-11-18T19:46:10Z

...d/core/src/main/java/org/sonarsource/sonarlint/core/telemetry/gessie/GessieSpringConfig.java

+  private static final String GESSIE_ENDPOINT = "https://events.sonardata.io";
+  private static final String IDE_SOURCE = "CiiwpdWnR21rWEOkgJ8tr3EYSXb7dzaQ5ezbipLb";
+
+  @Bean


Nitpick but you can define a name with @Bean(name = xxx), just to make sure it doesn't break if someone changes the name of the method, as you prefer

I would prefer to leave it. I like how Spring allows you to declare stuff without repeating yourself. And if somebody want to rename it they're better to do it everywhere anyway. So I would consider it a good thing that they're forced to do that.

nquinquenel · 2025-11-18T19:54:27Z

API_CHANGES.md

 * Introduce a new `org.sonarsource.sonarlint.core.rpc.protocol.backend.labs.IdeLabsRpcService` service and a `joinIdeLabsProgram` method.
  * Use it to allow users to join the SonarQube for IDE Labs program
  * The method accepts user email and IDE name as parameters
+* Add a new `GESSIE_TELEMETRY` value in `org.sonarsource.sonarlint.core.rpc.protocol.backend.initialize.BackendCapability`. Clients using the feature need to declare it at initialization time.


Nitpick:

Replace by: Add a new xxx capability [...]

From the point of view of the clients, how do they know if they should add this capability? I'd add a bit more guidance

nquinquenel · 2025-11-18T19:55:54Z

test-utils/src/main/java/org/sonarsource/sonarlint/core/test/utils/SonarLintBackendFixture.java

+    public SonarLintBackendBuilder withGessieTelemetryEnabled(String endpointUrl) {
+      this.backendCapabilities.add(GESSIE_TELEMETRY);
+      System.setProperty(PROPERTY_GESSIE_ENDPOINT, endpointUrl);
+      return this;
+    }


As I mentioned above, I think we should try to rely on actual dev/staging environment and not a specific mocked endpoint

We would be able to use this part to set dev/staging later on, maybe even by default. Also then would make sense to think about speeding up retries to avoid handing tests.

nquinquenel · 2025-11-18T19:58:57Z

medium-tests/src/test/java/mediumtest/gessie/GessieIntegrationMediumTests.java

+    this.oldDebugValue = InternalDebug.isEnabled();
+    InternalDebug.setEnabled(true);
+    environmentVariables.set("SONARLINT_HTTP_RETRY_INTERVAL_SECONDS", "0");
+    System.setProperty(GessieSpringConfig.PROPERTY_GESSIE_API_KEY, "value");


We may want to clear this system property after each test

nquinquenel · 2025-11-18T20:00:50Z

medium-tests/src/test/java/mediumtest/gessie/GessieIntegrationMediumTests.java

+  private static final String IDE_ENDPOINT = "/ide";
+  public static final String FAILED_ONCE = "Failed once";


NItpick: we usually define public attributes first and then private

Actually meant to make it private, fixed that.

sonarqube-next · 2025-11-19T11:35:48Z

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
92.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

Krosovok added 2 commits November 5, 2025 11:06

SLCORE-1787 Define the base payload schema and simple message payload.

a196b6d

SLCORE-1788 SLCORE-1789 SLCORE-1791 Send basic Gessie event

e02bc99

Krosovok requested a review from nquinquenel November 7, 2025 07:44

hashicorp-vault-sonar-prod bot changed the title ~~Feature/slcore 1647 gessie integration~~ SLCORE-1815 Feature/slcore 1647 gessie integration Nov 7, 2025

Krosovok added 2 commits November 17, 2025 13:31

SLCORE-1790 retries for Gessie

fd86251

SLCORE-1790 retries for Gessie

7f983fa

Krosovok marked this pull request as ready for review November 17, 2025 12:32

Krosovok added 2 commits November 17, 2025 13:46

Merge branch 'refs/heads/master' into feature/SLCORE-1647-gessie-inte…

c1e3415

…gration

SLCORE-1809 Update license

7ad4a5d

Krosovok force-pushed the feature/SLCORE-1647-gessie-integration branch 3 times, most recently from 90a3595 to 06ac3ed Compare November 18, 2025 15:08

nquinquenel reviewed Nov 18, 2025

View reviewed changes

SLCORE-1815 Use SQ:IDE key.

9368134

Krosovok force-pushed the feature/SLCORE-1647-gessie-integration branch from 06ac3ed to 9368134 Compare November 19, 2025 10:55

Krosovok requested a review from nquinquenel November 19, 2025 12:08

		private static final String IDE_ENDPOINT = "/ide";
		public static final String FAILED_ONCE = "Failed once";

SLCORE-1815 Feature/slcore 1647 gessie integration #1568

Are you sure you want to change the base?

SLCORE-1815 Feature/slcore 1647 gessie integration #1568

Uh oh!

Conversation

Krosovok commented Nov 7, 2025 • edited by atlassian bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sonarqube-next bot commented Nov 7, 2025

Quality Gate passed

Uh oh!

nquinquenel left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqube-next bot commented Nov 19, 2025

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Krosovok commented Nov 7, 2025 •

edited by atlassian bot

Loading