Make it suitable for contribute to https://github.com/php/php-src sending pull requests to there
Closed this issue · 7 comments
In the way it is, we need to put new tests in the folder phpt of this repository.
I think it could be good if we had some explanation of how to use this project to facilitate the flow that a contributor need to follow in order to send pull requests to https://github.com/php/php-src:
- git fork https://github.com/php/php-src to https://github.com//php-src
- git clone https://github.com//php-src in my machine
- git checkout the desired upstream branch
- git branch (that group of tests) and checkout this local branch
- create tests, tests the tests ;-) , and git commit
- git push to https://github.com//php-src
- open github pull from https://github.com//php-src 's branch (that group of tests) to https://github.com/php/php-src
- come back to my local repository, git checkout the desired upstream branch, rinse and repeat
@brunoric how do you suggest us to put everything together?
Best!
We are still waiting an answer from the guys in php-qa mail list to understand the best way of sharing the tests with them.
From the documentation if you are not a core committer you must send a pastbin (or gist in this days) to them. But we also think that it might be an easier way (via PR).
Problem with PR is: Which branch should we be aiming the merge? In theory it should aim the lowest branch still maintained (7.0.x). But you might aswell be writing a test to a new feature (or regression) on 7.1 or even 7.2. This would add an extra layer of complexity on the process with PRs for beginners.
Anyway, we sent already an email to the qa mail list and we are waiting for their support on this matter.
Anyway, we sent already an email to the qa mail list and we are waiting for their support on this matter.
@jpjoao can you confirm if the message is it: http://news.php.net/php.qa/67960 ?
From the documentation if you are not a core committer you must send a pastbin (or gist in this days) to them. But we also think that it might be an easier way (via PR).
@jpjoao Could you provide a link to that documentation?
Hi @rogeriopradoj, about the email that's the one! =)
Regarding the documentation link please take a look at this Write Test section at the PHP QA website.
Finally about your suggestion, I really think that is feasible! We still need to keep in mind that most of the extensions code and tests lives in different repositories and if we are writing tests for them we and we want to Pull Request, instead of simply sending the test to the QA list, we need to clone+commit+PR the right repository.
So what I'm thinking is this:
- implement a change change in the filename passed as argument in order to receive relative or full paths;
- implement a installer that will (a) download the phpqa repository to
~/.phpqaand (b) expose thephpqacommand to be used globally.
With that the user simply installs and can write the test wherever he wants like inside of the php-src (or an extension) local repository and then he just pass the relative or full path of the phptthat is intended to be tested.
What you guys think about it?
From the documentation if you are not a core committer you must send a pastbin (or gist in this days) to them. But we also think that it might be an easier way (via PR).
@jpjoao Could you provide a link to that documentation?
Just to make it easier to find: http://qa.php.net/write-test.php#whattodo
As @brunoric mentioned, we have the extension tests on php/php-src but they are not directly merged there, they are merged on each extension project.
And, to run tests you need to compile PHP and run make test for that specific version (what we've aimed to simplify with this set of docker images). It becomes more of a problem rather than a solution.
The approach on the merged MR has a good balance between enabling new joiners to the phpqa world (who doesn't have karma and therefore will need to send files over to be merged) and enable the already committers to also use it too.
I don't see, at this moment, any feasible option to cover better all scenarios - from this project perspective -, but I strongly advise that the whole testFest is also used to improve the way we submit tests to php.
(Can I close this issue for now?)
@jpjoao for the core extensions is and the engine is kinda simple to clone+write+test+commit+push+PR. The only problem that I see there is finding the right branch out point. For PECL and other non core extensions we have a extra layer of complexity that is finding the right repository to clone and send the PR. But in both scenarios I think that now we can close this issue since the tool can be used globally.
IMHO would be great to document properly both workflows. The standard one, with clone+write+test+commit+push+PR and the simple one with write+test+gist.
=)
I agree.
It is more a document thing now rather than implementation. Therefore this can be closed.