GitCommitBear: Require the commit message contains a valid issue reference

[jayvdb]

Following on from #1112 , some users may want the commit log to not contain a URL, but use the #123 syntax.

Also, BitBucket only supports #123 or issue 123 issue #123, and doesnt support URLs.

[ghost]

@jayvdb I would like to work on this...

[ghost]

@jayvdb @Makman2 What we could do for this is give a setting say issue_reference_type and its values can be like this : issue_reference_type = full_url or issue_reference_type = short_url and check accordingly. If short_url is given short_url can match #123 type or issue 123 type whereas if full_url is given full_url will match full issue urls.

What are your thoughts and suggestions on this approach?

[jayvdb]

Imo this should be blocked on the other issue

[ghost]

@jayvdb which other issue are you referring to ?

[jayvdb]

See this issue description.

[ghost]

For now I'll find some other issue to work on then... 😃

[Makman2]

@dracarys09 anyway the issue is blocked, I like the idea 👍 You should allow to combine those values, like
issue_reference_type = short_url | full_url or (which is maybe better as we can reuse the coala typed_list type) issue_reference_type = short_url, full_url :)

[ghost]

@Makman2 yeah but some users would want to go for short_url type while others might prefer long_url type. By default we can check for the presence of any of these two types as you suggested if user does not provide issue_reference_type setting, otherwise we can check for the user defined setting. 😄

[Makman2]

yeah right haven't said something else :) But by default no check shall happen, so if a user wants to have at least a reference and he doesn't care whether it is a short or long url, we should allow to supply issue_reference_type = short_url, long_url, as omitting the setting completely means the user doesn't care whether any issue reference appears at all^^

[ghost]

yeah got your point...thanks for suggestions...hope that this issue gets unblocked soon...

[jayvdb]

Just remembered that loklak project requires a Fixes #123 at the beginning of the shortlog.
See https://github.com/loklak/loklak_server/pull/866/commits .
So, this isnt just about the 'commit body'.

[jayvdb]

Hmm, Fixes #123 at the beginning of the shortlog can already be done with shortlog_regex. The regex would need to contain the long list of available prefixes like (Fixes|Closes|...), but often people only want a subset of the supported keywords, usually only (Fixes|Closes) which isnt too complicated.

[Makman2]

Hm maybe we can add convenience support, though I wouldn't concentrate on shortlogs yet^^

[ghost]

@jayvdb @Makman2 In check_issue method there is a parameter require_url and it's value can be short_ref, long_ref which is already checking for short and full references. I think we should just modify check_shortlog to check issue reference in shortlog. Rest we can do by making some modifications in check_issue method... The setting in .coafile will still be require_url. There is no need to create an extra setting.

[Makman2]

right no extra setting, but the shortlog check should also happen in check_issue, otherwise stuff gets messy. In fact the issue check for the body could happen already in check_body, but it makes sense to keep check_issue^^

[ghost]

@Makman2 I have one more doubt... this might sound silly... since the changes should be made to check_issue but check_issue is written by @nkprince007 which is present at nkprince007@8835efa

and this method is not yet merged in coala-bears repo... What should I do ?

[Makman2]

Don't rely on his commit and introduce check_issue on your own. Depending on which commit gets merged faster, the responsible person has to fix merge conflicts

[ghost]

@Makman2 But his commit has some code which I think is really useful. Shouldn't it be wrong if I directly use that code ?

[Makman2]

in this case you should rebase onto his commit. To do so you should checkout his branch via git fetch origin pull/<ID-of-pull-request>/head:<some-branch-name>, branch off your own and work on that. But remember that he might change his commits^^

[ghost]

@Makman2 I think his commit is in final stages as he just updated his PR with unit tests and all and I thing his commit will be merged in 3-4 days... Can I resume working on this after his commit gets merged and meanwhile start working on some other issue ?

[Makman2]

@dracarys09 sure :)

[jayvdb]

Note cross repo closes not yet supported is https://bitbucket.org/site/master/issues/15316/close-issues-with-a-commit-from-a-separate

c.f. #2467 for another BitBucket commit format.