-
-
Notifications
You must be signed in to change notification settings - Fork 74
PULL_REQUEST_{TO,FROM}_{HTTP,SSH}_CLONE_URL variables contains username #229
Comments
@christiangalsterer what do you think about removing the usernames? I'm asking because you introduced it in 001a9c7ce0d89b9 . I would vote for removing it. |
Hi, as long as we keep the variables (we heavily rely on it in our build pipeline) as such and remove only the username from the URL I'm fine with it. |
…ULL_REQUEST_{TO_FROM}_{HTTP,SSH}_CLONE_URL Signed-off-by: Jared Woolston <[email protected]>
#229 Proposed URI reconstruction to remove username from PULL_REQUEST…
Thanks to @jwoolston and his PR, this is now released in 3.20! |
I really appreciate the speedy release, this will help a lot, thank you. |
I don't really understand the justification in making this change. This broke our setup. What's the entire point behind stripping the username from the URLs? Right now git@stash:7999/project/PROJ/repo/REPO is coming out as stash:7999/project/PROJ/repo/REPO which seems broken to me. |
I'm thinking that the SSH clone URL should still have What do you say @johntconklin ? |
Thank you for considering -- That would be ideal for our use-case. |
Fixed in 3.22. |
Radical. Thank you @tomasbjerre. |
I'm no longer in an organization that uses Bitbucket, but if I recall correctly the SSH URL's included the name of the user who raised the pull request, not a generic "git@". So a pull request raised by user "foo" had a URL [email protected]:/project/PROJ/repo/REPO, and as a result, the build service account used for builds triggered by the event could not use the URL as-is, because it did not have credentials for "foo". To my mind, the URL and the access credentials are two completely separate things, and as such, the user should not be included in the URL. @theucke, you may want to follow this. |
Ssh URLs have git as the username I assure you.
Respectfully, Steven Behnke
|
I've found that using the PULL_REQUEST_{TO,FROM}_{HTTP,SSH}_CLONE_URL variables inconvenient to use as is, because of the username in the URL. My agents that use the URL don't use that username (and could not, because it doesn't have the password for that username). I don't know whether there is a use case where the username is useful, in which case, the username could be removed. But if there is a use case, please consider adding another set of _URL variables that don't include username.
The text was updated successfully, but these errors were encountered: