Search query for PRs returns metrics for issues about issue-metrics

[andrewgbell]

Solved my own problem... Not sure if it's worth a doc change, but if wanting to search for pr's, make sure the permissions are enabled at the start (rather than just write for issues, eg:

permissions:
issues: write
pull-requests: read

[paul-uz]

Setting the pull-requests permission seems to have fixed it. @zkoppert you'll probably want to include this in the docs :)

Thanks @andrewgbell for the tip.

[philnielsen]

at least for my use case, I figured out the problem. I was trying to edit your code a bit to try something and didn't fully understand yet! can't speak to paul's problem however, but mine at least was unrelated to this issue.

Thanks for open sourcing this and sorry for the noise on this issue (hope you can help paul)!

[paul-uz]

Definitely had PRs created in June.

Will try type:pr and see what happens.

[zkoppert]

I haven't been able to reproduce this. Here's what I'm doing and maybe you can tell me if there is something different.

I've got this as my search query:

SEARCH_QUERY='repo:github/issue-metrics is:pr created:2023-06-18..2023-06-24'

That returns this as the results which are all pull requests:

Issue Metrics

Metric	Value
Average time to first response	1 day, 6:34:31
Average time to close	2 days, 9:22:10
Number of items that remain open	0
Number of items closed	2
Total number of items created	2

Title	URL	Time to first response	Time to close
Allow for measuring discussions	#32	1 day, 6:34:31	4 days, 18:39:18
fix: count reviews as responses	#30	None	0:05:02

[paul-uz]

Query looks basically the same.

The response from the PR query lists issue titles in the workflow logs, so something fundamentally isn't right

[philnielsen]

I am seeing the same thing, I think it is because this looks to only work for PRs that have issues attached (and it actually uses the Issues API instead of the PR api, so it pulls the metrics to related Issues instead of the PR?).

[zkoppert]

is there an open source repository we can troubleshoot/reproduce this on or should I create one?

[zkoppert]

Maybe we should be using type:pr instead of is:pr?

[zkoppert]

I tested to see if it pull only metrics related to issues and it does not appear to work that way. Not in the output below that many of the pull requests do not have associated issues.

SEARCH_QUERY='repo:github/issue-metrics is:pr'

Output:

Issue Metrics

Metric	Value
Average time to first response	2 days, 9:54:16.571429
Average time to close	9:45:10.151515
Number of items that remain open	1
Number of items closed	33
Total number of items created	34

Title	URL	Time to first response	Time to close
docs: Add team assignment	#63	None	None
bug: add exception handling	#62	0:18:46	0:18:51
docs: Add permissions write to example workflows	#61	None	0:45:38
docs: enhance setup instructions	#56	0:27:15	5:41:14
Fix permissions documentation	#55	None	0:10:42
fix version typos	#54	None	0:09:06
fix iterator handling so issues don't get lost	#50	None	0:04:12
docs: fix docs on hiding columns	#48	None	0:05:35
feat: add time in labels	#45	1 day, 14:59:24	1 day, 16:01:31
feat: add JSON output	#42	None	16:24:41
feat: Configurable column hiding	#40	13 days, 18:52:47	0:24:05
fix: use general term items instead of issues	#35	None	0:05:50
Update docs for discussions searching	#34	None	0:04:39
Allow for measuring discussions	#32	1 day, 6:34:31	4 days, 18:39:18
fix: count reviews as responses	#30	None	0:05:02
Add use-cases	#27	None	4 days, 1:20:07
infra: add docker to dependabot	#25	None	0:05:33
Add example for calculated time range	#23	None	3:10:23
update base image to newer python version	#22	None	0:51:29
Fix type issues	#21	None	0:07:03
improve test coverage	#20	None	0:04:11
Docs updates	#19	None	0:32:10
Add proper type annotations (and some refactorings)	#18	2:15:50	1 day, 4:09:15
refactor: search_query naming should not specify it is only for issues.	#16	None	0:23:03
fix: time to first response being none caused sort failure	#15	None	4:02:06
feat: add time to close	#14	None	1:02:19
test: improve test coverage	#13	None	0:26:22
feat: add issue open and close counts	#11	None	2:20:18
handle and test no issues found case	#10	None	0:03:54
Correct Readme usage instructions	#8	None	0:13:26
clean up and formatting	#5	None	0:11:25
Add badges	#4	None	0:04:41
docs: Add project description	#2	None	1:45:20
build(deps): Bump ryan-rozario/pipreqs-action from 2.0.0 to 2.7.0	#1	1:51:23	1:57:06

[zkoppert]

Thanks for reporting back @philnielsen. Glad its working for you!!

[paul-uz]

Is my query going to return PRs created in said month, if they have been merged and closed?

Does type:pr work? I might try that.

[zkoppert]

Yes, the query you mentioned,

repo:owner/repo is:pr created:${{ env.last_month }}
should return all pull requests (both open and closed) as long as they were created in June (last month).

When I test out type:pr is works the same as is:pr, but maybe you will get different results. Interested to hear.

This also makes me think, did your repo have any pull requests that were created in June? If not, I wouldn't expect any results.

[andrewgbell]

I'm experiencing a similar thing, if I use the query in the UI:
repo:**** is:pr created:2023-06-01..2023-06-30

I get over 100 pr's, however running this inside the action I get:
Starting issue-metrics search...
Searching for issues...
No issues found

[paul-uz]

Solved my own problem... Not sure if it's worth a doc change, but if wanting to search for pr's, make sure the permissions are enabled at the start (rather than just write for issues, eg:

permissions:
issues: write
pull-requests: read

I'll add this and report back