feat: collect the services Jira issues link to, up to their latest change - #6
Merged
Merged
Conversation
…ange collect --jira KEY (repeatable) reads the issues and their GitLab links and collects every linked project. Rows run from the production baseline to the newest row an issue links to, and each service records its release: the nearest tag at or above that row, or in production, not merged, or not found, with open merge requests and merges into other branches listed. The page names the issues, shows the tag to release, and marks linked rows. The cache now prunes only within the projects a run collected, so group and --jira runs can share one file, and it keeps merged merge requests.
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.
Third step of the Jira phase: a report scoped to Jira issues.
What changes
collect --jira KEY(repeatable,-j) reads the issues, then collects every GitLab project their remote links point to. It needs the Jira settings and cannot be combined with--group/--project; keys are validated against the Jira key pattern.Row.linked).release:pendingwithtag: the nearest tag at or above the target (with its pipeline), or no tag when a new one is needed;in_production: every linked merged MR is outside the range (below production);not_merged: only open MRs link to the project;not_found: nothing linked is in the range, or the walk was truncated.Open MRs are listed as
pending_merge_requests; MRs merged into another branch become warnings.1withJira has no issue KEY.release <tag>orneeds a new tag,⏳ not merged/⚠️ linked change not foundneed attention,🎯marks linked rows; in-production services collapse as up to date.--jiraruns share one file; merged MRs are cached as settled facts. Cacheschema_versionstays 1 (additive field).Design notes
merged_at.in_productionrequires an untruncated walk; withmax_commitshit, the state isnot_foundrather than a false "deployed"._walk, shared by both modes.