I’m not a PHP track maintainer, so I’m in no position to make any decisions here. I’m just trying to tease out the value proposition here.
This may or may not matter much. Without seeing the cost of the current implementation and expected savings, this is hard to quantity in any meaningful way.
The test runners typically are set and forget, with most the maintenance done by the track maintainer. Making community contributions easier isn’t much of a factor when there isn’t any call for community contributions (and, in fact, those are auto closed).
This isn’t much of a priority if the codebase rarely changes and has been working fine for a while.
I don’t know many of those words, so I can’t comment. If there’s no plans on upgrading, that win isn’t really relevant. If this is an important step towards something the track maintainers are planning on doing, this might be of high value.
I completely understand your point of view and I am pretty happy to get your feedback. I did open the issue before doing anything else to get this kind of valuable feedback.
Comparing Docker and Docker we can expect a reduction in size from 285MB to 35MB so a 85% size reduction.
With caching this may not reduce the costs a lot. Performance wise I do not expect the PHP implementation to consume much less ressource as most of them are consumed by PHPUnit which is kind of obligatory.
I agree, I can see that test runners are rarely touched. I still think those can be interesting piece of codes for learning purposes.
Tests would add confidence that the test runner would behave as expected on certain scenario.
I do not know if there are any plans on upgrading, I can see that the issue is open since ~1.5 years and I guess the track could benefit from this feature. Furthermore it does not look really feasible with the current aproach (we could try to go with groups or re-invoke php with the results to try to get test context but this seems very hacky).