fix: correct comparison in remote parser when using custom ports

Mattias Michauxrequested to merge
fix/support-non-default-ports into main

Description

When a GitLab instance is running on a non default port (http on port 80, https on port 443), and the repo is cloned over SSH, the auto matching between the instance URL and the GitLab repo doesn't work.

This is caused by a wrong comparison, where the left side (GitLab instance) contains host:port , but the left side (repo URL) contains host

The comparison should be on the host alone, as for ssh:// remotes its very unlikely that the ports would match.

This MR addresses this

Related Issues

Resolves #1941 (closed)

How has this been tested?

  • Run an instance of GitLab on a non default port (I ran GDK containerized via the GDK-in-a-box)
  • open the extension in debug mode (e.g. via the f5 button)
  • authenticate your instance in the Workflow Extension (using f1 -> Gitlab: authenticate)
  • clone a repo (manually or via the clone functionality in vscode) from your local instance (e.g. git clone ssh://git@gdk.local:2222/flightjs/Flight.git)
  • go to the source control tab and see that the URL is not matched
  • apply the patch, and reload the extension in the debug window
  • go to the source control tab and see that the URL was automatically matched

Observations in the console:

before

2025-11-18T20:36:48:083 [info]: Extracted urls: [
      "ssh://git@gdk.local:2222/flightjs/Flight.git"
    ]
2025-11-18T20:36:48:415 [info]: Found 0 projects for urls: [
      "ssh://git@gdk.local:2222/flightjs/Flight.git"
    ]

after

2025-11-18T20:36:48:083 [info]: Extracted urls: [
      "ssh://git@gdk.local:2222/flightjs/Flight.git"
    ]
2025-11-18T20:36:48:415 [info]: Found 1 projects for urls: [
      "ssh://git@gdk.local:2222/flightjs/Flight.git"
    ]
  • 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
Edited by Mattias Michaux

Merge request reports