search

semantic-release / cli

:cl::round_pushpin: Setup automated semver compliant package publishing
MIT License
367 stars 46 forks source link

Add support for Gitlab #172

Open kbrandwijk opened 6 years ago

kbrandwijk commented 6 years ago

As Gitlab is now fully supported by semantic-release, it should also be supported by the CLI.

Tasks (that I can think of):

gr2m commented 6 years ago

maybe it could derive the default for the git host question from the "repository" setting in package.json, if present

Add command-line parameter for GL_TOKEN

Unless this is a common convention, I’d prefer GITLAB_TOKEN

kbrandwijk commented 6 years ago

GITLAB_TOKEN is also fine. To be honest, I didn't check the naming yet in the new Gitlab plugin.

Deriving repository default from package.json sounds like a great idea. I am just a bit worries that we can't derive that much from the url. Github.com and Gitlab.com are easy, but GHE and Gitlab can both be self-hosted too, so I think we can't get rid of that question completely...

https://docs.npmjs.com/files/package.json#repository

pvdlg commented 6 years ago

Both GH_TOKEN, GITHUB_TOKEN, GL_TOKEN and GITLAB_TOKEN are supported everywhere.

Regarding the repository we should use read-pkg to read the user's package.json which normalize the package.json including the repository url. We just have to make sure that when we save back the package.json we use the original version (to not save the normalization).

hosted-git-info can be used to determine if the repository URL is a GitHub, GitLab or Bitbucket URL. If it's a private GitLab or GHE then we'll have to ask the question.