Skip to content

formatSshUrl function doesn't handle self-hosted Git instances #2925

@Edzilla2000

Description

@Edzilla2000

Bug description 🐞

We are currently testing terrakube, and we use a self-hosted gitlab instance. I have configured workspaces using git ssh as the source without using the gitlab integration.

The formatSshUrl function in the Terrakube UI fails to properly convert SSH URLs to HTTPS for self-hosted GitLab/GitHub/Bitbucket instances. It only handles hardcoded domains (github.com, gitlab.com, bitbucket.org), leaving the colon in SSH URLs unconverted for any other domain.

Version Affected

Terrakube 2.28.0 (UI component)

Root Cause

In the minified UI bundle, there are two similar functions:

fixSshURL (correct implementation):
i.replace(":", "/").replace("git@", "https://")
This correctly handles any SSH URL by:

  1. First replacing : with /
  2. Then replacing git@ with https://

formatSshUrl (buggy implementation):
// Only handles specific domains:
i.includes("github.com") && (i = i.replace(".com:", ".com/"))
i.includes("gitlab.com") && (i = i.replace(".com:", ".com/"))
i.includes("bitbucket.org") && (i = i.replace(".org:", ".org/"))
i = i.replace(".git", "")
i = i.replace("git@", "https://")

The problem is that formatSshUrl has no fallback for domains not in the hardcoded list. Self-hosted instances like gitlab.example.com or github.mycompany.com are not handled.

Workaround

Users can apply a local patch by:

  1. Extracting the JS bundle from the container
  2. Adding support for their specific domain
  3. Mounting the patched file back into the container

Example patch for gitlab.example.com:
// Add after the bitbucket.org check:
i.includes("gitlab.example.com") && (i = i.replace(".com:", ".com/"))

Additional Context

  • The fixSshURL function elsewhere in the codebase handles this correctly with a generic approach
  • This affects any organization using self-hosted Git servers (GitLab CE/EE, GitHub Enterprise, Bitbucket Server)
  • The bug only affects URL display/linking in the UI; workspace execution may still work if the executor handles SSH URLs differently

Steps to reproduce

  1. Create a workspace with an SSH source URL pointing to a self-hosted GitLab instance:
    git@gitlab.example.com:myorg/myrepo.git
  2. Navigate to the workspace in the Terrakube UI
  3. Observe that the repository link is broken/invalid

Actual Behavior

The URL is partially converted, leaving an invalid URL with a colon:
https://gitlab.example.com:myorg/myrepo

This happens because the colon between the domain and path is not replaced with a slash.

Expected behavior

The SSH URL should be converted to a valid HTTPS URL:
https://gitlab.example.com/myorg/myrepo

Example repository

No response

Anything else?

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinggood first issueGood for newcomershelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions