fix(vloer): match checkouts by forge host and full repo path #157

ryangr0 · 2026-10-03T00:23:27Z

ryangr0 commented

2026-10-03 00:23:27 +00:00

remoteMatches in the VS Code extension kept only the last two path parts of
a git remote and compared them to owner/repo, so a clone of the same-named
repository on another forge, or under another GitLab group, was offered as
the Work Item's checkout. decodeURIComponent ran outside the try/catch, so a
badly encoded remote threw instead of not matching.

parseRemote now reads HTTPS, ssh:// (any port) and SCP-style remotes into a
lowercase host and the full path, keeping nested groups and stripping .git;
a malformed or badly encoded remote yields no identity and no match. The
checkout builds the expected repository from the host of the Work Item's
pull request link, the same link the clone offer already uses, and owner/repo
from Ploeg's target. Ploeg's target carries only a forge registry id, so
without a pull request link the full path is matched on any host.

A forge's SSH host often differs from its web host, so hosts also match when
both have at least three labels and share the parent domain below their
first label (forgejo-ssh.webgrip.dev and forgejo.webgrip.dev), or when the
new application-scoped setting vloer.remoteHostAliases maps one to the other.

Refs: VIK-1722

Co-Authored-By: Claude Opus 5.5 (1M context) noreply@anthropic.com

Hosts match when equal, when mapped by the new vloer.remoteHostAliases setting (application scope), or when both have 3+ labels and share the parent domain (forgejo-ssh.webgrip.dev ~ forgejo.webgrip.dev). Before a PR link exists the host is unknown and any host matches the full path; a full fix needs Ploeg to expose the target's forge host.

Verified with mise run verify on the pinned toolchain (all gates passed).

Ticket: https://vikunja.webgrip.dev/tasks/1722

🤖 Generated with Claude Code

remoteMatches in the VS Code extension kept only the last two path parts of a git remote and compared them to owner/repo, so a clone of the same-named repository on another forge, or under another GitLab group, was offered as the Work Item's checkout. decodeURIComponent ran outside the try/catch, so a badly encoded remote threw instead of not matching. parseRemote now reads HTTPS, ssh:// (any port) and SCP-style remotes into a lowercase host and the full path, keeping nested groups and stripping .git; a malformed or badly encoded remote yields no identity and no match. The checkout builds the expected repository from the host of the Work Item's pull request link, the same link the clone offer already uses, and owner/repo from Ploeg's target. Ploeg's target carries only a forge registry id, so without a pull request link the full path is matched on any host. A forge's SSH host often differs from its web host, so hosts also match when both have at least three labels and share the parent domain below their first label (forgejo-ssh.webgrip.dev and forgejo.webgrip.dev), or when the new application-scoped setting vloer.remoteHostAliases maps one to the other. Refs: VIK-1722 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Hosts match when equal, when mapped by the new vloer.remoteHostAliases setting (application scope), or when both have 3+ labels and share the parent domain (forgejo-ssh.webgrip.dev ~ forgejo.webgrip.dev). Before a PR link exists the host is unknown and any host matches the full path; a full fix needs Ploeg to expose the target's forge host. Verified with `mise run verify` on the pinned toolchain (all gates passed). Ticket: https://vikunja.webgrip.dev/tasks/1722 🤖 Generated with [Claude Code](https://claude.com/claude-code)

ryangr0 added 1 commit

2026-10-03 00:23:28 +00:00

fix(vloer): match checkouts by forge host and full repo path

[Workflow] On Pull Request / release-policy (pull_request) Failing after 18s

Details

[Workflow] On Pull Request / checks (pull_request) Successful in 8m3s

Details

[Workflow] On Pull Request / warnings (pull_request) Successful in 0s

Details

255dbf4a37

remoteMatches in the VS Code extension kept only the last two path parts of
a git remote and compared them to owner/repo, so a clone of the same-named
repository on another forge, or under another GitLab group, was offered as
the Work Item's checkout. decodeURIComponent ran outside the try/catch, so a
badly encoded remote threw instead of not matching.

parseRemote now reads HTTPS, ssh:// (any port) and SCP-style remotes into a
lowercase host and the full path, keeping nested groups and stripping .git;
a malformed or badly encoded remote yields no identity and no match. The
checkout builds the expected repository from the host of the Work Item's
pull request link, the same link the clone offer already uses, and owner/repo
from Ploeg's target. Ploeg's target carries only a forge registry id, so
without a pull request link the full path is matched on any host.

A forge's SSH host often differs from its web host, so hosts also match when
both have at least three labels and share the parent domain below their
first label (forgejo-ssh.webgrip.dev and forgejo.webgrip.dev), or when the
new application-scoped setting vloer.remoteHostAliases maps one to the other.

Refs: VIK-1722

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

ryangr0 merged commit 01ec821d0c into development

2026-10-03 00:31:41 +00:00

ryangr0 referenced this pull request from a commit

2026-10-03 00:31:43 +00:00

Merge pull request 'fix(vloer): match checkouts by forge host and full repo path' (#157) from ryangr0/vloer-extension-remote-identity into development

Sign in to join this conversation.

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

webgrip/unfold!157

Rows
Columns