-
Notifications
You must be signed in to change notification settings - Fork 33
Use a more generic way to pull repo name #81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
Because folder name can change, getting the repo name from the folder name is dangerous. See https://stackoverflow.com/a/42543006
Running |
Co-authored-by: Jay Vercellone <[email protected]>
Hey @jverce, how can I merge the PR? |
@@ -85,8 +85,11 @@ export default class ServerlessGitVariables { | |||
break | |||
} | |||
case 'repository': { | |||
const pathName = await _exec('git rev-parse --show-toplevel') | |||
value = path.basename(pathName) | |||
const firstRemoteName = await _exec('git remote | head -1') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if the better option here would be to default to origin and allow a config escape hatch instead of assuming the first remote is the right one (I also think this isn't guaranteed to work on all systems, since not all systems have access to head
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jacob-meacham thinking out loud, no need to change the default behavior, so we won't break any legacy system using this plugin, and use a config escape to override the behavior and use git config --get remote.origin.url
. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm compelled by your case - I think that this is strictly more correct (though I'd release it as a breaking change), so I think we should just go for it and either add configuration to set the remote you want to pull or just use origin which I expect is right the vast majority of cases
Hey @jverce, not yet. |
Apologies, this fell off my radar! @efimk-lu would you mind adding a legacy escape for people relying on the old behavior, along with config to explicitly set the remote (defaulting to the first in the list is fine, but nice to let users specify a remote). Once that's done I'll merge and release |
@jacob-meacham Using the folder name is annoying. Would this be the config logic you want? I might take the time to implement it. Can someone hint me at docs on how to define config parameters? (parameter names below are just for illustration purposes. feel free to suggest good names) If |
Extracting the repo name from the folder into which the git repo was cloned is dangerous. Mainly because the folder name can change. This is a more robust way of pulling it.
See https://stackoverflow.com/a/42543006