`nx release` fails to create GitHub releases with Git remotes pointing to fully qualified SSH URLs

[ekkolon]

Current Behavior

When running the nx release task in a project where Git is configured to connect to GitHub via SSH over HTTPS (using port 443), the release step fails to create a GitHub release.

This failure only occurs if the Git remote URL is not in one of the push formats officially documented by GitHub:

• HTTPS: https://github.com/user/repo.git
• SSH (shorthand): git@github.com:user/repo.git

However, when the Git remote points to a fully qualified SSH URL over port 443, nx release fails to correctly extract the user/repo slug:

# git remote -v

origin  ssh://git@ssh.github.com:443/ekkolon/nxdemo.git (push)

In this case, nx release incorrectly extracts the slug as 443/ekkolon instead of ekkolon/nxdemo.

Expected Behavior

nx release should correctly extract the user/repo slug from all valid GitHub remote URL formats, including canonical SSH URLs with a port.

Users shouldn't have to manually reconfigure their Git remotes to get nx release to create a GitHub release.

GitHub Repo

No response

Steps to Reproduce

1. Configure GitHub and Git to use SSH over HTTPs
2. Clone or create and push a GitHub repo configured to use nx release
3. Run git remote -v
4. If your Git origin points to a fully qualified SSH URL run nx release
5. nx release creates the git tag and pushes it
6. nx release tries to create a GitHub release with the generated changelog but fails

I created a minimal reproducable example in the TypeScript Playground, where I modified the GithubRemoteReleaseClient.resolveRepoData() method suspected of causing the issue.

I replaced the inner CMD call to git remote -v with a hard-coded, fully qualified SSH URL: ssh://git@ssh.github.com:443/ekkolon/nxdemo.git

When you run this example, you should see the following in the logs:

{
  "hostname": "github.com",
  "apiBaseUrl": "https://api.github.com",
  "slug": "443/ekkolon"
} 

Nx Report

N/A

Failure Logs

Package Manager Version

pnpm 10.12.1

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

Suspected Root Cause

This behavior appears to stem from the GithubRemoteReleaseClient#resolveRepoData() method, which uses a regex to extract the slug from the Git remote URL.

However, the regex currently only handles:

• SSH-style shorthand: git@github.com:ekkolon/nxdemo.git
• HTTPS: https://github.com/ekkolon/nxdemo.git

It does not match fully qualified SSH URLs with a port, such as:

ssh://git@ssh.github.com:443/ekkolon/nxdemo.git

Workaround

Manually updating the Git remote to the SSH format supported by GitHub prior to using nx release command resolves the issue:

git remote set-url origin git@github.com:ekkolon/nxdemo.git

But this may not be ideal in environments where port 22 is blocked or SSH over HTTPS is the preferred default.

Ideally GithubRemoteReleaseClient#resolveRepoData() method should support extracting the user/repo slug from fully qualified SSH URLs too.

---

I'm happy to follow up with a PR if you agree this is something worth addressing.

[danielferrari]

The issue also happens when using GitLab as provider. I'm currently facing the same using a self-hosted instance of GitLab from my company.

Ex:

ssh://git@mygitlab.com:2222/my-company/nx/nx-demo.git

And this is the error I got when running nx release

 NX   A GitLab API Error occurred when creating/updating the release

GitLab Error: {"message":"404 Project Not Found"}
---
Request Data:
Repo: 2222/my-company/nx/nx-demo
Token Header Data: [object Object]
Body: {"tag_name":"my-lib/0.1.0","name":"my-lib/0.1.0","description":"## 0.1.0 (2025-06-26)\n\n### 🚀 Features\n\n- test release (https://mygitlab.com/2222/my-company/nx/nx-demo/-/commit/41e94dc91e)\n\n### ❤️ Thank You\n\n- Daniel Ferrari","prerelease":false,"ref":"4931f3627c1d23cfba8fd7120b7b928cd5ce7bf2","released_at":"2025-06-26T15:57:17.009Z","assets":{"links":[]},"milestones":[]}

Note that the link to the commit in the generated changelog file/request body is also wrong.

Could you please consider it in the proposed solution?

[ekkolon]

@danielferrari, thanks for the insight! I’ve looked into it, and the issue is caused by the same regex logic used to extract the slug.

I’ll work on a fix that covers both GitHub and GitLab release clients. In the meantime, I think it makes sense to keep the PR as a draft until the solution fully addresses both cases.