Closed Ayanmullick closed 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.
@HowardWolosky, Get-GitHubIssue
turns up blank.
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,
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.
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.
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.
(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).
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.
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.
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.
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.
I'm still waiting for a response on the below issue :smile:
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.
Submitted #1165588. Awaiting response.
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 -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.
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|2009PowerShell 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.0Module Version
Running: 0.16.0 Installed: 0.16.0