@uchandran Looks good to me, thanks!

Description

Updates mentions of agentic and classic versions of GitLab Duo Chat in UI copy to align with the latest guidance.

It also fixes a few other terminology mentions to align with the style guide - mainly, to ensure we're saying GitLab before Duo in most places (per legal guidance).

This is an update after closing !3010. It reflects the latest terminology confirmed in gitlab-org/gitlab!226691+

Related Issues

gitlab-org/gitlab#592624

How has this been tested?

⚠️ Does this MR include a GitLab Duo UI update? If so, please smoke test all webviews in a downstream project to ensure there are no visual regressions

• One of:
  • GitLab for VS Code extension (setup instructions).
  • GitLab JetBrains Plugin (setup instructions).

What CHANGELOG entry will this MR create?

• fix: Bug fix fixes - a user-facing issue in production - included in changelog
• feature: New feature - a user-facing change which adds functionality - included in changelog
• BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
• other non-user-facing changes

Mohammed Osumah (08cb3c8c) at 16 Mar 19:38

Mohammed Osumah (c6bf87b8) at 16 Mar 19:28

Description

This MR fixes the handling of the 422 error when users don't have a default GitLab Duo namespace selected. Previously, this error was not being surfaced to users, causing the usage quota check to pass incorrectly and allowing code suggestions to remain enabled when they shouldn't be.

Changes Made

1. Added isMissingDefaultNamespaceError() helper - Detects 422 errors with missing_default_duo in the response body
2. Enhanced CodeSuggestionsCreditsCheck - Now emits a missingDefaultNamespace event when the error is detected
3. Created CodeSuggestionsMissingDefaultNamespaceCheck - New state check that listens to the credits check and manages the missing namespace state
4. Added new state check type - SUGGESTIONS_NO_DEFAULT_NAMESPACE in the feature state management types
5. Integrated into priority order - The missing namespace check is prioritized before the credits check in CODE_SUGGESTIONS_CHECKS_PRIORITY_ORDERED

How It Works

1. When /api/v4/code_suggestions/direct_access returns a 422 error, the credits check detects it
2. The credits check emits a missingDefaultNamespace event
3. The missing namespace check listens to this event and updates its state
4. The feature state manager broadcasts the state change to the client
5. The client disables code suggestions based on the engaged state

Related Issues

Issue #1907

How has this been tested?

To test this MR, follow these steps:

1. Set up the GitLab LSP extension in your editor (VS Code or JetBrains)
2. Connect to a GitLab instance where you have a user account without a default namespace selected
3. Open a code file in your editor to trigger code suggestions
4. Verify that code suggestions are disabled and you see an error message indicating you need to select a default namespace
5. Go to your GitLab user preferences (Preferences - Behaviour) and select a default namespace for GitLab Duo
6. Reload the extension or reconnect
7. Verify that code suggestions are now enabled and working properly
8. Test the reverse scenario: remove your default namespace selection and verify that code suggestions are disabled again after reconnecting

⚠️ Does this MR include a GitLab Duo UI update? If so, please smoke test all webviews in a downstream project to ensure there are no visual regressions

• One of:
  • GitLab for VS Code extension (setup instructions).
  • GitLab JetBrains Plugin (setup instructions).

What CHANGELOG entry will this MR create?

• fix: Bug fix fixes - a user-facing issue in production - included in changelog
• feature: New feature - a user-facing change which adds functionality - included in changelog
• BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
• other non-user-facing changes

Passing this over to @erran for a maintainer review

Description

Many test files across the codebase define near-identical inline helpers for async generator operations — collecting yielded values, draining generators, creating generators from arrays. They all do the same thing but have different names in each file (createEventStream, collectGeneratorEvents, consumeAllGeneratorEvents, drainGenerator, etc.).

This adds three shared helpers to @gitlab-org/test-utils and replaces all the inline definitions across 7 test files.

Related Issues

Issue #2143

How has this been tested?

• checkout this branch
• mise install && npm install
• npm run test:unit

What CHANGELOG entry will this MR create?

• other non-user-facing changes

@elwyn-gitlab Changes look good to me!

Mohammed Osumah (33252c89) at 13 Mar 18:40

Thanks @jay_mccure the changes look good to me! I also retried the failing jobs in the pipeline for you

Description

This change removes the automated metrics collection system from the end-to-end testing pipeline. Previously, after running browser tests, the system would automatically send test results and performance data to an InfluxDB database for monitoring and analysis purposes.

The influx instance has been removed and this hasn't been working for 4+ months, prior to that, these metrics were not being used.

This will fix this warning: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/jobs/13463059948#L1311

Related Issues

gitlab-org/quality/analytics#30 (comment 2841647568) gitlab-org/quality/quality-engineering/team-tasks#4325

How has this been tested?

• If src/browser or src/common has been modified, please consider interoperability with the Web IDE. See Running the Extension in WebIDE.
• Consider an end-to-end test for significant new features that aren't covered by integration tests.

Screenshots (if appropriate)

What CHANGELOG entry will this MR create?

• fix: Bug fix fixes - a user-facing issue in production - included in changelog
• feature: New feature - a user-facing change which adds functionality - included in changelog
• BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
• None - other non-user-facing changes

@lauraionel can I ask for a first review of this MR? 🙏

Mohammed Osumah (22653c7a) at 13 Mar 02:38

@GitLabDuo I think www.gitlab.com is a permanent redirect to https://gitlab.com, so I think this should be fine

Not sure if we have to worry about this to be honest

Mohammed Osumah (fa821a1a) at 13 Mar 02:27

Mohammed Osumah (dcd74c0d) at 13 Mar 00:46

Description

Snowplow events are currently sent directly from the editor extensions. We want to route these events through the GitLab instance for a number of reasons:

1. Unifying how data is collected - this makes it easier to guarantee that events always have a specific shape etc.
2. Allowing administrator control - since it's all going through the instance it's easier to make sure data is only forwarded if appropriate.
3. Improving customer trust - no event data is sent individually to a strange snowplow address.

We need to support any versions of GitLab and both self-managed and gitlab.com.

GitLab instance	snowplowprd.trx.gitlab.net	Event forwarding
Gitlab.com - any version	X
SM - version < 18.0	X
SM - version >= 18.0		X

Implemented smart routing for Snowplow telemetry events based on GitLab instance version. Events are now routed through the GitLab instance for self-managed instances >= 18.0, while continuing to send directly to Snowplow for gitlab.com and self-managed instances < 18.0.

Changes

• Automatically detects GitLab instance version and routes events accordingly
  • Self-managed >= 18.0: Routes through {instance_url}/-/collect_events
  • Self-managed < 18.0 & gitlab.com: Routes to snowplowprd.trx.gitlab.net
  • Custom trackingUrl config still takes precedence over smart routing
• Listens to API reconfiguration events to update endpoint when connecting to different instances
• Created event_forwarding.ts with version comparison and endpoint determination logic
• Maintains backward compatibility
  • Do-not-track setting continues to be respected

Related Issues

Closes #2086

How has this been tested?

To manually test with GDK:

1. Start your local GDK

2. Start the extension host and open a workspace folder that was cloned from your gdk

3. Verify events are routed to <gdk_url>/-/collect_events for version >= 18.0

   

4. To test with older version, modify GDK's VERSION file to a version less than 18.0 (e.g. 17.6.0) and restart

5. Verify events are routed to snowplowprd.trx.gitlab.net for version < 18.0

   

6. Verify events are routed to snowplowprd.trx.gitlab.net for gitlab.com

7. Confirm telemetry is disabled when do-not-track setting is enabled

To manually test with Gitlab.com

1. Start the extension host and open a workspace folder that was cloned from gitlab.com
2. Verify events are routed to snowplowprd.trx.gitlab.net

1. Confirm telemetry is disabled when do-not-track setting is enabled

When custom tracking url is set:

• If the setting gitlab.trackingUrl is set, verify that the extension still respects it

⚠️ Does this MR include a GitLab Duo UI update? If so, please smoke test all webviews in a downstream project to ensure there are no visual regressions

• One of:
  • GitLab for VS Code extension (setup instructions).
  • GitLab JetBrains Plugin (setup instructions).

What CHANGELOG entry will this MR create?

• fix: Bug fix fixes - a user-facing issue in production - included in changelog
• feature: New feature - a user-facing change which adds functionality - included in changelog
• BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
• other non-user-facing changes

Closes #2086

Mohammed Osumah (9d6dc3a4) at 12 Mar 14:30

@ohoral changes look good to me!