fix: support nested group paths in SSH Git URLs#2379
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe SSH URL parsing regex in ChangesSSH URL nested path parsing
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
c216761 to
ddeba1e
Compare
What
SSH URL parser now accepts nested group paths (e.g.
git@host:group/subgroup/repo.git)Why
GitLab and self-hosted Git servers commonly use nested groups/subgroups in repository paths. The existing regex only matched two-segment
owner/repopaths, causing--custom-sourceto reject valid SSH URLs with "Not a valid Git URL or local path".How
([^/]+)to(.+?)inparseSource()([^/.]+?)still captures only the final path componentcacheKeyanddisplayNamenaturally extend to include the full owner pathTesting
Verified nested-group SSH URLs (e.g.
[email protected]:org/team/project.git) now parse correctly. Standard two-segment URLs ([email protected]:owner/repo.git) continue to work unchanged.