Refactored the MultiSelectWithSearch function and related interfaces to use a MultiSelectSearchResult struct instead of multiple return values. This change improves clarity and extensibility of the search function signature, and updates all usages, mocks, and tests accordingly.
Initial implementation of MultiSelectWithSearch:
- Implement by survey and accessible prompters. They use the same internal func under the hood.
- Implement in `gh preview prompter` for initial testing and demonstration
- Implement interface changes across the codebase and mocks to satisfy compiler.
- Implement tests for new MultiSelectWithSearch prompter
This commit enhances the following scenarios to include organization teams as pull request reviewers:
1. Interactive `gh pr create` during additional metadata
2. Tab completing `gh pr create --reviewer`
3. Tab completing `gh pr edit --add-reviewer`
4. Tab completing `gh pr edit --remove-reviewer`
Additionally, a new `gh pr create` test case for ensuring that teams show up within interactive prompts has been added.
- updated command documentation for new `--assignee @copilot` syntax
- updated `gh issue create` logic with feature detection for actor availability
- fixed bug where `--assignee` would not select default assignees due to login vs display name mismatch
- updated survey prompt logic to avoid parsing prompt options in favor of correlating with assignee / actor source
One thing that is not included in these changes is incorporating the GraphQL mutation to replace assignees with actors, which I will continue iterating on.
Currently, the prompter doesn't enforce the requirement of a title for PR
and Issue creation. However, that creates the UX where a user can enter a
blank title, spend time filling out a detailed body, then fail to create
the issue or pr when the request is sent to the api because the title is
blank. This attempts to handle that before sending a request to the api,
enforcing that, when prompting, the title of an issue is not blank.
For metadata types chosen in interactive flow, we fetch all records from
the API in order to be able to display a multi-select interface.
For metadata defined via command-line flags, we resolve records that can
be looked up directly, avoiding fetching the entirety of expensive
datasets (e.g. all members of an organization) if we can.
The new approach ensures efficient fetching when interactive flow is
combined with values from flags.