hallmark icon indicating copy to clipboard operation
hallmark copied to clipboard

GitLab subgroup results in "Unable to parse git host URL" error

Open mitar opened this issue 2 years ago • 7 comments

When running inside a git clone which is using SSH git location.

mitar avatar Dec 01 '21 13:12 mitar

Which version of hallmark, and do you have an example?

vweevers avatar Dec 01 '21 15:12 vweevers

Version 4.0.0. The full error is:

Error: Unable to parse git host URL "[email protected]:tozd/go/errors.git"

It looks like it might be connected with the fact that I use sub-group on GitLab?

mitar avatar Dec 01 '21 17:12 mitar

I'm not familiar with GitLab sub-groups, but judging by that URL, I'd guess so, yes. Note that hallmark is currently geared towards GitHub so you may run into other issues too (just a heads up).

vweevers avatar Dec 01 '21 17:12 vweevers

Support of sub-groups is blocked on https://github.com/npm/hosted-git-info/issues/54 which is used internally here.

vweevers avatar Dec 01 '21 17:12 vweevers

Addressing OP's use case seems to work with hosted-git-info 6.1.1:

hostedGitInfo = requires("hosted-git-info")
hostedGitInfo.fromUrl("[email protected]:tozd/go/errors.git")

I was able to use hallmark to autogenerate a draft changelog at my workplace for a repo that has a remote url like [email protected]:company/department/team/subteam/project-collection/project.git with the following addition to a local installation of hallmark's package.json:

  "overrides": {
    "hosted-git-info": "6.1.1"
  },

It's a bit scattered, but it seems that gitlab subgroups were marked as supported upstream in hosted-git-info #56 and hosted-git-info #43 (though this commit is supposedly in version 3.0.8 with which I also had this issue)

The use case in the hosted-git-info #54 issue linked as a blocker of this one has the overriding problem of self-hosted gitlab, which has been claimed in hosted-git-info #23 and #11to be out of scope for "hosted git info" as URL conventions for self-hosted version control systems (VCS) are not necessarily discernible from the domain.

It seems like the dreaded Conventional Commits tool tried and failed to fall back to provided domains, but I like their moxie. If the possibility of generating broken VCS links could be nonfatal or skipped, enabling the autogeneration of draft changelogs for self-hosted enterprise VCS users could greatly broaden the scope of adoption of this standard. It'd still be a draft requiring human review, and the target audience likely has enough familiarity with regexes or find-and-replace to fix any broken links.

I'm pretty new to node, so for my benefit as much as anyone else's, the commands specifically used to demonstrate success are within:

export PATH_TO_LOCAL_HALLMARK='/path/to/hallmark'
export PATH_TO_MY_REPO='/path/to/myrepo'
git clone https://github.com/vweevers/hallmark.git $PATH_TO_LOCAL_HALLMARK
cd $PATH_TO_LOCAL_HALLMARK
printf '{
  "override": {
    "hosted-git-info": "6.1.1"
  },' > tmpfile
awk 'NR > 1 {print}' package.json >> tmpfile
mv tmpfile package.json
npm install --save-dev .
npm link
cd $PATH_TO_MY_REPO
chmod +x ~/homebrew/lib/node_modules/hallmark/compat/cli.cjs
hallmark cc init

Observe new, nonempty file at $PATH_TO_MY_REPO/CHANGELOG.md.

dbrakman avatar Jan 04 '23 07:01 dbrakman

I am using GitHub and get the same error:

> hallmark lint CHANGELOG.md
Error: Unable to find git host
    at parse (C:\Users\koppor\AppData\Roaming\npm\node_modules\hallmark\node_modules\find-githost\index.js:129:11)
    at exports.fromGit (C:\Users\koppor\AppData\Roaming\npm\node_modules\hallmark\node_modules\find-githost\index.js:110:10)
    at repo (file:///C:/Users/koppor/AppData/Roaming/npm/node_modules/hallmark/index.js:224:13)
    at hallmark (file:///C:/Users/koppor/AppData/Roaming/npm/node_modules/hallmark/index.js:29:22)
    at Module.lint (file:///C:/Users/koppor/AppData/Roaming/npm/node_modules/hallmark/index.js:153:10)
    at file:///C:/Users/koppor/AppData/Roaming/npm/node_modules/hallmark/cli.js:33:14
    at ModuleJob.run (node:internal/modules/esm/module_job:194:25)

The issue is when using git worktree, when .git is a file and not I directory.

$ cat .git
gitdir: C:/git-repositories/jabref-all/jabref/.git/worktrees/jabref

koppor avatar Sep 08 '23 10:09 koppor

@koppor That's a separate issue. A PR is welcome over at https://github.com/vweevers/find-gitdir (which does support git-style symlinks, for support of submodules, but it may need something more to also support worktrees).

vweevers avatar Sep 08 '23 11:09 vweevers