[#286] - Feature Enhancement: Display PR status in the PT list.
- New
- Medium
- Build: master
- # 286
Steps to reproduce the issue
Patch tester doesn't display additional statuses of PRs that may impact their viability for testing.
It makes using the PT a little frustrating (especially for new users) to be playing Patch Roulette and end up coming up with a string of patches that perhaps aren't ones to be displayed as they're draft or otherwise not really a patch for testing.
Expected result
Show status or filter out PR statuses such as Draft where there's not actually something to test.
Actual result
You can't tell what the status of a PR is until you view it on J! Issue Tracker or Github.
Additional comments
Example 1:
joomla/joomla-cms#29196 was closed June 3
joomla/joomla-cms#29198 was the PR related to 29196 which was switched to draft May 26 by George Wilson. So there's not much point continuing testing it while it's a draft.
Example 2:
https://issues.joomla.org/tracker/joomla-cms/26722 is another in the Patch Tester that's a Draft, but it also is in the Unit Tests category, and isn't a typical PR - looks more like a note from George Wilson adding to a team task list.
I have no idea what I can do in terms of filtering issues but I will take a look at it and let you know.
The labels as can be seen in Github have now been added to the list:
Further I added a filter for NPM PRs:
So you can filter on the non-NPM PRs, those should be usable via the Patch Tester. I am not sure yet but I may just make this the default.
@richard67 I checked the status of the example PR of George, but I don't see in the data we get back from Github that it is Draft, so I do not know how Github knows that.
The Filter NPM patches works the same as Filter RTC status.
@roland-d Does this help joomla/jissues#1079? Or this joomla/jissues#1080? I think the first one should be the one.
As for draft statuses we cannot retrieve them with the current implementation of the Patch Tester.
| Labels |
Added:
on hold
|
||
Yes, we have to use the "pulls" API end point, e.g. https://api.github.com/repos/joomla/joomla-cms/pulls/26722?page=1&per_page=1 instead of or in addition to the "issues" end point, e.g. https://api.github.com/repos/joomla/joomla-cms/issues/26722?page=1&per_page=1, and that provides different data in the json.
As there's only 16 or so drafts at any time, to improve testing short term as you've implemented all of the other suggestions @roland-d could you look at making RC3 what you put in the BFH chat last weekend (made testing so much easier), and splitting off the draft issue to a new issue for RC4?
@particthistle The PT 4.0.0 RC 3 release is out and I think we should create a new issue for the draft issue. Care to create the issue?
@roland-d @particthistle Maybe a new issue not only for draft status but also for showing if a PR has conflicts or not? Could be the same change necessary for both.
I prefer 1 issue/request per ticket.
Then title and description of this issue have to be changed, because title talks about PR status, not about PR's draft status, and the description talks about statuses.
This issue will be closed and new ones created.
Display draft status makes sense. Not sure if that's possible though.
Display the "NPM Resource Change" GitHub label (maybe with a better title "Requires NPM" or just "NPM") might make sense, too, because those can't be tested with PT 4 as long as the CI method is not working reliably.
The same might apply to GitHub label "Composer Dependency Changed".
The "Unit Tests" GitHub label should be ignored. It is automatically set if some code for unit tests is touched or created. This might be a PR dealing ONLY with unit tests, but it also can be a PR adding a new feature including the necessary unit tests. You never know if it makes sense to test that using Patch Tester or not.