Repository navigation
Count Jira issues that reach a tag only through a GitLab link - #32
Merged
Merged
Conversation
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
1 participant
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.
Closes #31. The report's fields stay the same, so the schema stays at 6.
After Jira is read, every issue's key joins the
jira_keysof each row its GitLab links point to, and the candidates of the services it touches are rebuilt from those rows. A merge request link matches a row by iid and a commit link by SHA prefix, the same matching--jirauses for its target. This runs in group and--jiraruns alike.Before, a candidate's
jira_keyscame only from the text of its rows: a merge request's title, source branch and description, or a direct commit's message. GitLab links an issue on more mentions than that, such as a key in one commit message inside a merge request, so an issue could ship in a tag without being listed. The Jira tasks tab, the release post, the page'salso shipsandships anyway, and the skill's advice to merge picked candidates'jira_keysall missed it. In a--jirarun this could drop the very issue the run was asked about: with SHOP-12 linked only to !11, release tag 1.2.0 used to list no keys at all.Of the options in the issue, this is option 2, with one change. Group runs do not set
row.linked. On the page,linkedshows the 🎯 "Linked to the issues" mark for the issues a--jirarun was given; in a group run nearly every row with a key links to some issue, so the mark would stop meaning anything. Adding the key to the row is enough for the candidates.Option 1, reading keys from the commit messages inside merge requests, was not taken: it would also pick up keys GitLab did not link, such as one quoted in a revert.
The README intro and
SKILL.mdnow say a row'sjira_keysinclude linked issues. The skill's>=0.8,<0.9range still holds.Tests, written first and failing before the change: an issue linked to a merge request that does not name it joins that row and the 1.2.0 candidate, and a row that already names an issue does not get it twice; an issue linked to a commit joins the row holding it; in a
--jirarun, the release tag's candidate lists the scope issue its target does not name.just test-ci(132 passed, 100% coverage) andjust lint-cipass.