Provide more helpful error message

[scarf005]

Status Quo

currently, failure message does not describe why the check failed.

semantic-prs/functions/src/handle-pull-request-change.ts

Lines 90 to 102 in afe753c

	function getSemanticState(): SemanticState {
	if (!config.enabled) {
	return new InfoSemanticState(true, 'skipped; check enabled in semantic.yml config');
	} else if (config.titleOnly) {
	return new SuccessFailureSemanticState(hasSemanticTitle, 'ready to be squashed', 'add a semantic PR title');
	} else if (config.commitsOnly) {
	if (config.anyCommit) {
	return new SuccessFailureSemanticState(
	someCommitsSemantic,
	'ready to be merged or rebased',
	'add a semantic commit',
	);
	} else {

The problem

while using semantic PR in https://github.com/cataclysmbnteam/Cataclysm-BN, we found out that new contributors had a hard time figuring out why their PR failed. for example:

I have no clue what the Semantic PR bot is angry about with my latest PR's title, but oh well. At least all the actually important tests came back okay lol

giving context-aware error message will help new contributors greatly.

The Proposal

make error message aware of configuration context. for example, with this configuration, each error cases could have been:

Malformed syntax

 feat : foo 

• hint: remove invalid leading space before type feat
• hint: remove invalid space between type feat and :
• hint: remove invalid trailing space after description foo

-  feat : foo 
+ feat: foo

Invalid type

feature: foo

• invalid type feature.
• accepted types are: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert.
• hint: did you mean feat?

- feature: foo
+ feat: foo

Invalid Scope

feat(): bar

• empty scopes are not allowed.
• hint: remove ()

- feat(): bar
+ feat: bar

feat(ui): baz

• invalid scope ui.
• accepted scopes are: content, UI, i18n, balance, ...
• hint: did you mean UI?

- feat(ui): baz
+ feat(UI): baz

Additional Context

• I'm interested in opening a PR.
• If errors are too long to fit in, adding error comment might be better.

[Ezard]

Good suggestion!

Perhaps it would be best if the app commented on your PR with these details, as opposed to trying to squash them into the status description...although this would mean requesting more permissions from users, which I'm hesitant to do

An alternative would be to make use of the status link, and pass some data to a webpage that can explain why the check passed / failed

[scarf005]

i'm leery on using external link as in my experience almost no one found out that details link to an web site.