I wanted to open an issue to discuss this one before I ran off and wrote the code.
Currently (as noted in the README), `UTF-8` in a commit message will trigger push failure when they're interpreted as a missing JIRA issue.
I've been writing a lot of UTF-8 related code lately, so this issue is something I'd like to solve. My proposed changes:
This provides a direct tool for resolving well-known issue key conflicts, eg, UTF-*:
Add a new regex configuration option that specifies explicit lookup exclusions. If a discovered issue key matches this regexp, and the issue isn't found in JIRA, the error will be ignored. For example: `UTF-(8|16|32)`
If you actually have a 'UTF' project key:
Issue lookup will still work; the error suppression simply avoids treating a failed lookup as an error
If the lookup fails and no other issue identifiers are found, the "No JIRA Issue found in commit message." error will still trigger.
*Project Key Validation:*
This provides a more general solution that should work in the majority of cases, while also still catching commit messages that fail to include any valid issue reference:
After matching likely issue keys, extract the project key part (ie, (KEY)-BUGNUM)
Use the JIRA REST API to [fetch the project metadata](https://docs.atlassian.com/software/jira/docs/api/REST/latest/#d2e4255), which includes the project key.
If the project is not found (404), ignore the issue key; it will not trigger an error, and it will not be used for validation.
If the project is found, and result.key == project key part, use the issue key for validation.
We have to explicitly check the project key returned by the REST API, rather than simply treating a 200 response as a found project: The REST API accepts `projectIdOrKey`; ie, it could return a valid project listing for a value that is not actually a key.
Plus, it's a bit more fail-safe than just assuming a 200 response means JIRA found the project, without ever actually parsing the server response.