feat: add issue link list and delete commands#43
Conversation
Add --list flag to show all links on an issue with ID, relation, linked issue key and summary. Add --delete flag to remove a link by ID (validates link exists on the issue first). API additions: GetIssueLinks, DeleteIssueLink on JiraService.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces valuable new functionality for managing issue links by adding commands to list and delete them. The implementation is well-structured and follows the existing patterns in the codebase. The API service layer is cleanly extended with GetIssueLinks and DeleteIssueLink functions. The command-level logic in internal/cmd/issue/link.go is robust, handling different argument counts for create, list, and delete operations. I particularly appreciate the pre-flight check in runDeleteLink that verifies a link exists on the specified issue before attempting deletion, which greatly improves user safety and experience. I have one suggestion to make the argument validation even more robust.
| if opts.ListTypes { | ||
| return nil | ||
| } |
There was a problem hiding this comment.
The argument validation for --list-types could be made more strict. Currently, if a user provides arguments with this flag (e.g., atl issue link --list-types some-arg), the arguments are ignored. It would be better to return an error to inform the user that this flag does not accept arguments. This improves the command's robustness and provides clearer feedback to the user.
if len(args) != 0 {
return fmt.Errorf("the --list-types flag does not accept any arguments")
}
return nil
Merging this branch will decrease overall coverage
Coverage by fileChanged files (no unit tests)
Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code. |
Summary
atl issue link PROJ-1 --list— show all links on an issue (ID, relation, linked key, summary)atl issue link PROJ-1 --delete <id>— remove a link by ID (validates it exists first)Closes the gap where links could be created but never inspected or cleaned up.
API additions
GetIssueLinks(ctx, issueKey)— fetchesissuelinksfield from issueDeleteIssueLink(ctx, linkID)—DELETE /rest/api/3/issueLink/{id}Test plan
make check— lint + tests passatl issue link NX-15370 --listshows links with correct relation/summaryatl issue link NX-15370 --delete 132186removed a stale Blocks link--list-typesand create flow unchanged