[INS-1054] Remove .git suffix requirement for custom git repository URL - #9086
Conversation
36aae8a to
c572aa2
Compare
| <Input | ||
| type="url" | ||
| pattern="https?://.*\.git" | ||
| pattern="https?://.+" |
There was a problem hiding this comment.
@godfrzero After testing this PR I noticed the following issue
The pattern we use now https?://.+ it will match spaces, symbols, or query strings that might not be valid URLs.
- Examples 1
- Example 2
Allow multiple URLs
It's better to use this pattern https?://[^\s]+. This pattern is a safer choice for matching most common URLs with a path, while avoiding false matches or truncated links.
- Requires domain
- Stops at spaces
- Still allows .git or no .git
|
@godfrzero An alternative approach would be to rely on the browser’s built-in validation instead of enforcing a custom pattern, since the .git suffix is optional. I’ve also applied a small improvement to the parseGitToHttpsURL function to prevent potential crashes. This keeps the implementation simpler and more robust overall. |
4739972 to
0e16a29
Compare
0e16a29 to
77bdd30
Compare
|
Refraining from merging this for now because I'm seeing some strange behavior in the local build. Will test more tomorrow and figure out what's going on. |
77bdd30 to
c47a31f
Compare
This was happening because the |
| // final URL fallback for any other git URL | ||
| temp = new URL(temp).href; | ||
| parsed = temp; | ||
| tempURL = (URL.canParse(tempURL) ? URL.parse(tempURL)?.href : url) || ''; |
There was a problem hiding this comment.
@pavkout Should the code not throw an error instead of settling on '' in case everything fails?
There was a problem hiding this comment.
@godfrzero This function’s purpose is to parse the given URL. In Node.js, calling new URL(temp).href behaves differently than in the browser, which can lead to issues. To handle that discrepancy, we introduced this logic. The actual validation, is performed on the client side.
Not all providers will use a URL ending in .git. The requirement makes sense for Github/Gitlab, but not for a form which can connect to any git server.
…r git repositories
a6559fc to
e209f55
Compare
|
Verified with an Azure DevOps repo that cloning, pushing, and pulling changes all work as expected. |
2 participants
Not all providers will use a URL ending in .git. The requirement makes sense for Github/Gitlab since we know which conventions they follow, but not for a form which can connect to any git server. For example, Azure DevOps repo URLs don't end in
.gitand customers report that manually adding it results in a 404.Note that I have not been able to test cloning an Azure DevOps repo myself, so this PR just makes two changes:
.gitwhen adding a URL in the Git—a.k.a. custom repository settings—form.