Skip to content

feat: collect the services Jira issues link to, up to their latest change - #6

Merged
lesnik512 merged 1 commit into
mainfrom
feat/jira-scope
Sep 29, 2026
Merged

lesnik512 merged 1 commit into
mainfrom
feat/jira-scope

Conversation

@lesnik512

Copy link
Copy Markdown
Member

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.
  • Per project, rows run from the production baseline to the target: the newest row whose merge request or commit an issue links to. Rows above it are dropped; linked rows are marked (Row.linked).
  • Each scoped service gets a release:
    • pending with tag: 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.
  • Row keys outside the scope are still read from Jira, so summaries, statuses and related services work as in group mode.
  • A scope key Jira does not return exits 1 with Jira has no issue KEY.
  • Page: title and intro name the issues, one line per issue, the Pending cell shows release <tag> or needs a new tag, ⏳ not merged / ⚠️ linked change not found need attention, 🎯 marks linked rows; in-production services collapse as up to date.
  • Cache: prunes only within projects the run collected, so group and --jira runs share one file; merged MRs are cached as settled facts. Cache schema_version stays 1 (additive field).

Design notes

  • The target is chosen by position in first-parent history, not merged_at.
  • in_production requires an untruncated walk; with max_commits hit, the state is not_found rather than a false "deployed".
  • A project whose path from the link cannot be read becomes a failed service with the GitLab error; it does not stop the run.
  • The range walk moved into _walk, shared by both modes.

…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.
@lesnik512
lesnik512 merged commit b5a7ca7 into main Sep 29, 2026
12 checks passed
@lesnik512
lesnik512 deleted the feat/jira-scope branch September 29, 2026 13:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant