fix(validator): accept JIRA keys that contain digits - #49
Merged
Merged
Conversation
The old pattern required all letters before all digits. A key such as A11Y-160 mixes them, so the validator rejected it. The new pattern needs one uppercase letter first. It then accepts letters and digits in any order. It stays a superset of the old pattern, so LUM-1234 and LUM12-345 remain valid.
gcornut
marked this pull request as ready for review
September 4, 2026 09:53
noirbee
approved these changes
Sep 4, 2026
Member
Author
|
Tested this regex against every JIRA project key on our Atlassian site (131 keys), by running the real
Headroom check: the longest key in use is 7 chars (the pattern allows 13), and the highest issue number in use is 5 digits (the pattern allows 6). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The validator rejects a JIRA key that mixes letters and digits, such as
A11Y-160.The old pattern put all letters before all digits:
[A-Z]{2,7}needs a minimum of two letters at the start.A11Ygives one letter only, so the match fails. A commit of typefeatorfixthen exits with code 9 (ERROR_JIRA). Both placements fail: the footer line, and the header with--jira-in-header.Change
The new pattern needs one uppercase letter first. It then accepts letters and digits in any order:
The new pattern is a superset of the old one:
LUM-1234andAB-123remain valid.LUM12-345remains valid.A11Y-160becomes valid.A key must still start with an uppercase letter.
a11y-160and11Y-160stay invalid.Tests
7 new tests in
validator.bats:A11Y-160in the footer.A11Y-160in the header, withGLOBAL_JIRA_IN_HEADER.a11y-160.11Y-160.featcommit withA11Y-160.fixcommit withLUM12-345.a11y-160.All 107 tests pass locally with bats-core.
Known limit, not changed here
JIRA_HEADER_PATTERNguards the capture with[^A-Z]. A digit satisfies that guard. A header key such asAB1CD-45therefore capturesCD-45only. This behaviour is the same before and after this change, so I left it alone.