This PR updates gh to use advanced issue search, if available.

Here are a couple of notes regarding the changes:

• The search package (in pkg/search) is a general-purpose/independent component that handles the search for a couple of other commands. That is why, it now supports is:blocked, is:blocking or even handles the combination of is:merged and is:unmerged in a query, although no other part of the code actually uses these. It's just to eliminate the extra knowledge about what other packages need.

• For mock feature detectors, where a feature detector was need but it's not really important for the test case (like asserting something other than the query), a mock that reflects the current status of the advanced issue search is used (which is supported as opt-in). This is to keep the tests up-to-date with the state of github.com and reflect the fact that gh prefers advanced issue search if it's available on the host.

• For test cases where the code path should not involve any feature detection (e.g. when a list operation should take place, rather than a search), a nil detector is passed.

• Two markers added to the code to help us identify the places we need to change in the future:

  • // TODO advancedIssueSearchCleanup: actionable when GHES 3.17 goes out of support and we don't need to maintain compatibility with the old issue search backend.
  • // TODO advancedSearchFuture: actionable when the advanced search syntax is available on global search or Pull Requests tabs.

A/C verification

A. On github.com

1. gh search issues (REST API)

When I run these commands:

gh search issues --sort created --repo cli/cli --repo cli/go-gh hyperlink
gh search issues --sort created --repo cli/cli --match title,body,comments foo
gh search issues --sort created --repo cli/cli --visibility private,public foo
gh search issues --sort created --owner @me --owner cli

Then the result is not empty, the query contains OR-ed qualifiers, and the API request URL includes the advanced_search=true query parameter

All confirmed, just an example here. HTTP request (note the advanced_search=true):

/search/issues?advanced_search=true&page=1&per_page=30&q=hyperlink+%28repo%3Acli%2Fcli+OR+repo%3Acli%2Fgo-gh%29+type%3Aissue&sort=created

URL-decoded query:

hyperlink (repo:cli/cli OR repo:cli/go-gh) type:issue

When I run above commands with --web
Then I see the old search syntax (i.e. no OR-ed qualifiers) in the global search GUI

Confirmed:

2. gh search prs (REST API)

When I run these commands:

gh search prs --sort created --repo cli/cli --repo cli/go-gh hyperlink
gh search prs --sort created --repo cli/cli --match title,body,comments foo
gh search prs --sort created --repo cli/cli --visibility private,public foo
gh search prs --sort created --owner @me --owner cli

Then the result is not empty, the query contains OR-ed qualifiers, and the API request URL includes the advanced_search=true query parameter

All confirmed, just an example here. HTTP request (note the advanced_search=true):

/search/issues?advanced_search=true&page=1&per_page=30&q=hyperlink+%28repo%3Acli%2Fcli+OR+repo%3Acli%2Fgo-gh%29+type%3Apr&sort=created

URL-decoded query:

hyperlink (repo:cli/cli OR repo:cli/go-gh) type:pr

When I run above commands with --web
Then I see the old search syntax (i.e. no OR-ed qualifiers) in the global search GUI

Confirmed:

3. gh issue list (GraphQL)

Given I'm in the local clone of the cli/cli repo
When I run gh issue list --search gh --label bug (to enforce a search API call)
Then the result is the same as it would when using the latest gh release, and the type argument is set to ISSUE_ADVANCED

Confirmed (note the ISSUE_ADVANCED):

GraphQL variables: {"limit":30,"owner":"cli","query":"gh label:bug repo:cli/cli state:open type:issue","repo":"cli","type":"ISSUE_ADVANCED"}

The results are the same:

$ diff <(gh issue list --search gh --label bug) <(./bin/gh issue list --search gh --label bug)
$ echo $?
0

Given I'm in the local clone of the cli/cli repo
When I run gh issue list --search gh --label bug --web
Then the pre-populated query is the same as it would when using the latest gh release

Confirmed. On latest gh:

Current PR:

4. gh pr list (GraphQL)

Given I'm in the local clone of the cli/cli repo
When I run gh pr list --search gh --label external (to enforce a search API call)
Then the result is the same as it would when using the latest gh release, and the type argument is set to ISSUE_ADVANCED

Confirmed (note the ISSUE_ADVANCED):

GraphQL variables: {"limit":30,"q":"gh label:external repo:cli/cli state:open type:pr","type":"ISSUE_ADVANCED"}

The results are the same:

$ diff <(gh pr list --search gh --label external) <(./bin/gh pr list --search gh --label external)
$ echo $?
0

Given I'm in the local clone of the cli/cli repo
When I run gh pr list --search gh --label external --web
Then the pre-populated query is the same as it would when using the latest gh release

Confirmed. On latest gh:

Current PR:

B. On GHES 3.17

Asserting the GHES instance version:

GH_HOST="<HOST>" gh api /meta --jq '.installed_version' | cat
# 3.17.0

1. gh search issues (REST API)

When I run

GH_HOST="<HOST>" USER="<USER>" gh search issues --sort created --repo "$USER/repo-a" --repo "$USER/repo-b" foo

Then the result is the same as it would when using the latest gh release, the query does not contain OR-ed qualifiers, and the API request URL does not include the advanced_search=true query parameter

Confirmed. Both show the same output (although expected 2, not 2x2 hits!):

Showing 4 of 4 issues

REPO            ID  TITLE  LABELS  UPDATED           
babakks/repo-b  #1  foo            about 13 hours ago
babakks/repo-b  #1  foo            about 13 hours ago
babakks/repo-a  #1  foo            about 14 hours ago
babakks/repo-a  #1  foo            about 14 hours ago

Also, no advanced_search=true and no ORs in query in the HTTP request:

GET /api/v3/search/issues?page=1&per_page=30&q=foo+repo%3Ababakks%2Frepo-a+repo%3Ababakks%2Frepo-b+type%3Aissue&sort=created HTTP/1.1

When I run above commands with --web
Then I see the old search syntax (i.e. no OR-ed qualifiers) in the global search GUI

Confirmed; since the GUI does not show the query here's the browser's address bar:

2. gh search prs (REST API)

When I run

GH_HOST="<HOST>" USER="<USER>" gh search prs --sort created --repo "$USER/repo-a" --repo "$USER/repo-b" foo

Then the result is the same as it would when using the latest gh release, the query does not contain OR-ed qualifiers, and the API request URL does not include the advanced_search=true query parameter

Confirmed. Both show the same output (this time really 2 hits!):

Showing 2 of 2 pull requests

REPO            ID  TITLE  LABELS  UPDATED           
babakks/repo-b  #2  foo            about 14 hours ago
babakks/repo-a  #2  foo            about 14 hours ago

Also, no advanced_search=true and no ORs in query in the HTTP request:

GET /api/v3/search/issues?page=1&per_page=30&q=foo+repo%3Ababakks%2Frepo-a+repo%3Ababakks%2Frepo-b+type%3Apr&sort=created HTTP/1.1

When I run above commands with --web
Then I see the old search syntax (i.e. no OR-ed qualifiers) in the global search GUI

Confirmed; since the GUI does not show the query here's the browser's address bar:

3. gh issue list (GraphQL)

Given I'm in the local clone of one the repos
When I run gh issue list --search foo (to enforce a search API call)
Then the result is the same as it would when using the latest gh release, and the type argument is set to ISSUE

Confirmed the outputs are the same (although it should be only one hit, not two!):

Showing 2 of 2 issues in babakks/repo-a that match your search

ID  TITLE  LABELS  UPDATED           
#1  foo            about 14 hours ago
#1  foo            about 14 hours ago

Also type is ISSUE:

GraphQL variables: {"limit":30,"owner":"babakks","query":"foo repo:babakks/repo-a state:open type:issue","repo":"repo-a","type":"ISSUE"}

Given I'm in the local clone of one the repos
When I run gh issue list --search foo --web
Then the pre-populated query is the same as it would when using the latest gh release

Confirmed. On latest gh:

Current PR:

4. gh pr list (GraphQL)

Given I'm in the local clone of one the repos
When I run gh pr list --search foo (to enforce a search API call)
Then the result is the same as it would when using the latest gh release, and the type argument is set to ISSUE

Confirmed the outputs are the same:

Showing 1 of 1 pull request in babakks/repo-a that matches your search

ID  TITLE  BRANCH      CREATED AT        
#2  foo    new-branch  about 14 hours ago

Also type is ISSUE:

GraphQL variables: {"limit":30,"q":"foo repo:babakks/repo-a state:open type:pr","type":"ISSUE"}

Given I'm in the local clone of one the repos
When I run gh pr list --search foo --web
Then the pre-populated query is the same as it would when using the latest gh release

Confirmed. On latest gh:

Current PR: