profile
viewpoint

Ask questionsSync git remote parsing logic

Issue with git remote parsing logic

  1. User has a private bitbucket server, with .git/config remote: url = ssh://git@bitbucket.companyxyz.com/~steve.steve/netlify-test.git

  2. user uses netlify init --manual and we create a repo with a bad spec: Repo.path is set to ~steve.steve/netlify-test.git meaning we don't try to reach his server when cloning and fail

  3. user uses netlify sites:create --manual --with-ci and it works correctly, setting Repo.path to git@bitbucket.companyxyz.com:~steve.steve/netlify-test.git which works well.


It would appear that init and sites:create are using a slightly different git remote parsing mechanism.

one uses parseGitRemote https://github.com/netlify/cli/blob/master/src/commands/sites/create.js#L119 looks like its working and the other uses getRepoData https://github.com/netlify/cli/blob/master/src/commands/init.js#L61 which appears to not be working

The git remote parsing logic appears to be different for each.

It appears that the parsing logic for netlify sites:create --manual --with-ci is working correctly in the scenario above

netlify/cli

Answer questions verythorough

Ah, I see what you mean now. However, since that UI field is directly connected to the "automatic" setup for continuous deployment, I think that would actually be a much bigger change than fixing the bug in this issue.

In the end, maintaining two different commands that do essentially the same thing doesn't really make sense. I suspect that the best path forward is to make sure sites:create includes all of the functionality of init and then gradually deprecate init.

useful!

Related questions

'socket hang up' error thrown randomly hot 1
Github User Rank List