microsoft / PowerShellForGitHub

Microsoft PowerShell wrapper for GitHub API
Other
584 stars 184 forks source link

Query the list of Issues across repositories by user #329

Closed Ayanmullick closed 3 years ago

Ayanmullick commented 3 years ago

A description of your problem or question

I'm unable to query the list of Issues across repositories by user.

Steps to reproduce the issue

   Get-GitHubUser -UserName ayanmullick |Get-GitHubIssue
Get-GitHubUser -UserName ayanmullick |Get-GitHubIssue -Verbose #Verbose logs showing the problem ``` VERBOSE: [0.16.0] Executing: Get-GitHubIssue -Verbose:$true -Creator "Ayanmullick" VERBOSE: Getting issues across owned, member and org repositories VERBOSE: Accessing [Get] https://api.github.com/issues?filter=assigned&state=open&sort=created&direction=desc&creator=Ayanmullick [Timeout = 0)] VERBOSE: GET https://api.github.com/issues?filter=assigned&state=open&sort=created&direction=desc&creator=Ayanmullick with 0-byte payload VERBOSE: received 2-byte response of content type application/json VERBOSE: [0.16.0] Executing: Set-TelemetryEvent -EventName "Get-GitHubIssue" VERBOSE: Sending telemetry event data to https://dc.services.visualstudio.com/v2/track [Timeout = 0)] VERBOSE: POST https://dc.services.visualstudio.com/v2/track with 1692-byte payload VERBOSE: received 49-byte response of content type application/json ```

Suggested solution to the issue

One is able to get issues by repository

Get-GitHubIssue -RepositoryName test -OwnerName ayanmullick|Get-GitHubIssue

But I couldn't get the Issues I created even if we loop across repositories.

$repos=Get-GitHubRepository -OwnerName microsoft
$repos|% {(Get-GitHubIssue -State Open).Where{$_.user.login -eq 'Ayanmullick'}

There should be a way to get the Issues one has created in GitHub across repositories. Like https://github.com/issues; in PowerShell.

Operating System |Property|Value| |:--|:--| |OsArchitecture|64-bit |OsLanguage|en-US |OsMuiLanguages|{en-US, en-GB} |OsName|Microsoft Windows 10 Enterprise N |OsOperatingSystemSKU|WindowsEnterprise |WindowsBuildLabEx|19041.1.amd64fre.vb\_release.191206-1406 |WindowsVersion|2009
PowerShell Version |Property|Value| |:--|:--| |GitCommitId|7.1.3 |OS|Microsoft Windows 10.0.19043 |Platform|Win32NT |PSCompatibleVersions|{1.0, 2.0, 3.0, 4.0, 5.0, 5.1.10032.0, 6.0.0, 6.1.0, 6.2.0, 7.0.0, 7.1.3} |PSEdition|Core |PSRemotingProtocolVersion|2.3 |PSVersion|7.1.3 |SerializationVersion|1.1.0.1 |WSManStackVersion|3.0

Module Version

Running: 0.16.0 Installed: 0.16.0

HowardWolosky commented 3 years ago

Getting all the issues assigned to an arbitrary user is not a supported action by the GitHub REST API. Getting all the issues assigned to the authenticated user is supported by both the API and PowerShellForGitHub. You just do this:

Get-GitHubIssue

Getting the list of issues opened by a given user is also not a supported feature of the GitHub REST API (but might be possible with GraphQL (see below)).

Regarding your second point, your syntax is off. This part of the syntax:

$repos |% { <next thing> }

means "for each repo, do <next thing>. It's not piping in the $repo from the current iterator to Get-GitHubIssue. If you want to do that, then don't use the foreach (|%) syntax...just pipe:

$repos | <next thing>

The correct way to write a PowerShellForGitHub command that looped through a set of repos to return the set of Issues that were opened by you is this:

Get-GitHubRepository -OwnerName microsoft |
    Get-GitHubIssue -State Open | 
    Where-Object { $_.user.login -eq 'Ayanmullick' }

or even more simply:

Get-GitHubRepository -OwnerName microsoft |
    Get-GitHubIssue -State Open -Creator 'Ayanmullick' # Creator/UserName can only be used when querying against a specific repo

In conclusion, if you want to know all issues currently assigned to the authenticated user, just call Get-GitHubIssue with no additional parameters. If you want to be able to query for that same information for a generic user, that might be possible with GraphQL, but that hasn't been implemented yet within this module (although #313 is quite close to merging initial GraphQL support). If you want to check for opened and/or assigned issues for a generic user across a finite set of repositories, that is easily accomplishable with the current module when the proper syntax is used.

Ayanmullick commented 3 years ago

@HowardWolosky, Get-GitHubIssue turns up blank.

image

Secondly, thanks for rectifying the syntax. However,

Get-GitHubRepository -OwnerName microsoft |  Get-GitHubIssue -State Open | 
    Where-Object { $_.user.login -eq 'Ayanmullick' }

takes >2 hrs to run and would be inconvenient for automation purposes. I'm just looking for all issues currently assigned to the authenticated user. The first method didn't work and the second method doesn't scale.

HowardWolosky commented 3 years ago

@HowardWolosky, Get-GitHubIssue turns up blank.

Are you authenticated? Can you provide the verbose log output for that command? If you have configured DefaultOwnerName and/or DefaultRepositoryName, that will prevent you from using this command as desired, since you will be in fact specifying those values.

Get-GitHubRepository -OwnerName microsoft |  Get-GitHubIssue -State Open | 
    Where-Object { $_.user.login -eq 'Ayanmullick' }

takes >2 hrs to run and would be inconvenient for automation purposes. I'm just looking for all issues currently assigned to the authenticated user. The first method didn't work and the second method doesn't scale.

The first command will do precisely what you are asking for when authenticated, provided that you're not specifying any other parameter.

Ayanmullick commented 3 years ago

Yes @HowardWolosky, I have authenticated using a PAT. And I haven't specified any DefaultOwnerName or DefaultRepositoryName. PFB verbose output for Get-GitHubIssue -Verbose

VERBOSE: [0.16.0] Executing: Get-GitHubIssue -Verbose:$true
VERBOSE: Getting issues across owned, member and org repositories
VERBOSE: Accessing [Get] https://api.github.com/issues?filter=assigned&state=open&sort=created&direction=desc [Timeout = 0)]
VERBOSE: GET https://api.github.com/issues?filter=assigned&state=open&sort=created&direction=desc with 0-byte payload
VERBOSE: received 2-byte response of content type application/json
VERBOSE: [0.16.0] Executing: Set-TelemetryEvent -EventName "Get-GitHubIssue"
VERBOSE: Sending telemetry event data to https://dc.services.visualstudio.com/v2/track [Timeout = 0)]
VERBOSE: POST https://dc.services.visualstudio.com/v2/track with 1692-byte payload
VERBOSE: received 49-byte response of content type application/json

Get-GitHubRepository -OwnerName microsoft|Get-GitHubIssue -State Open|Where-Object { $_.user.login -eq 'Ayanmullick' } is providing the output as expected. But it takes >2 hrs.

HowardWolosky commented 3 years ago

The only other reason I can think of that would explain why it's not working for you, is if you haven't authorized that PAT to be able to disable SSO for the microsoft org.

image (via here)

Try taking this simply....create a new public repo under your own profile and open an issue in it. Then call Get-GitHubIssue -Filter All to see if you get it back:

$repo = New-GitHubRepository -RepositoryName TestIssueRepo -AutoInit
$issue = $repo | New-GitHubIssue -Title 'First Issue'
Get-GitHubIssue -Filter Created

At the minimum, you should see that issue which you just created (I've just verified this all myself).

Ayanmullick commented 3 years ago

Get-GitHubIssue -Filter Created -State Open is able to get 50% of my open issues. @HowardWolosky, Maybe the underlying API has limitations the cmdlet should take into account.

HowardWolosky commented 3 years ago

Seems more like a bug/issue on the server side for what results are being returned. Reviewing the API once more, there are a few optional parameters that the cmdlet doesn't expose. See if this returns anything additional:

Invoke-GHRestMethodMultipleResult -UriFragment 'issues?filter=created&state=open&sort=created&direction=desc&collab=true&orgs=true&owned=true&since=2000-01-01T00:00:00Z' -Description 'Get All Created Issues'

Beyond that, if you still aren't seeing all of your issues, then I'd encourage you to open a forum post here which references the underlying REST API call that you're making (which you can see in the verbose output) and a reference to an issue that isn't being returned. Maybe that will help them identify the issue on the server side. Given that I can't repro the issue, it wouldn't be of much use for me to open the issue myself as I wouldn't be able to provide any additional detail.

Ayanmullick commented 3 years ago

Seems more like a bug/issue on the server side for what results are being returned. Reviewing the API once more, there are a few optional parameters that the cmdlet doesn't expose. See if this returns anything additional:

Invoke-GHRestMethodMultipleResult -UriFragment 'issues?filter=created&state=open&sort=created&direction=desc&collab=true&orgs=true&owned=true&since=2000-01-01T00:00:00Z' -Description 'Get All Created Issues'

Beyond that, if you still aren't seeing all of your issues, then I'd encourage you to open a forum post here which references the underlying REST API call that you're making (which you can see in the verbose output) and a reference to an issue that isn't being returned. Maybe that will help them identify the issue on the server side. Given that I can't repro the issue, it wouldn't be of much use for me to open the issue myself as I wouldn't be able to provide any additional detail.

This returns the same 11 issues as Get-GitHubIssue -Filter Created -State Open

One could create an issue in a non-Microsoft-owned repository, @HowardWolosky, and see if it shows up when one runs the above cmdlets. I recommend keeping the issue open until resolution.

HowardWolosky commented 3 years ago

One could create an issue in a non-Microsoft-owned repository, @HowardWolosky, and see if it shows up when one runs the above cmdlets. I recommend keeping the issue open until resolution.

That's already been validated by the previous suggestion. As far as I can tell with the information provided thus far, this doesn't appear to be an issue with how the module is calling the API, but rather an issue with the API itself.

I will once again encourage you to open an issue in the support forum referencing the API that you're calling (seen in the verbose output) and a sample issue that isn't being returned, and see if you get a response.

Ayanmullick commented 3 years ago

I'm still waiting for a response on the below issue :smile:

https://github.community/t/powershell-sdk-for-github/15770

HowardWolosky commented 3 years ago

Well, in that issue you're asking them to create and maintain an entirely new SDK, so I'm not surprised it didn't see a lot of traction. I'm suggesting that you create an issue that calls attention to a potential bug in their existing API, one that would impact all clients. I would expect that would get more traction/response.

Ayanmullick commented 3 years ago

Submitted #1165588. Awaiting response.