--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/gi5MC2FrzjAJ.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
We could hook into Travis, which would be the most visible automation.But from what I can tell, we can't run the sniffer against diffs.So for now, even if your changes are adhereing to the conventions,but the file you changed is not, the sniffer will fail, right?
If that's the case, we need to fix up core first, which won't be a trivial exercise.There's a project which might help with the basic bits: https://github.com/fabpot/PHP-CS-FixerIts written by the Symfony lead dev, and applied to Symfony code, so should be fairly solid.
That won't fix stuff like wrong class/method naming conventions of course,of which we have plenty - those will be a slow deprecation cycle to fix.
For any automation, we'd need to suppress those errors to keep the output meaningful.Overall, I think the most useful mid-term application would be a diff of the sniffer error output,which should be doable in CI (at least for TeamCity, not sure for Travis in terms of persistence).
If we can add a whitelist of any incompatible method names, then we can still include the test and use to ensure that no new names are introduced. Alternatively, we could only allow incompatible method names if they are @deprecated, but I don't know how hard that is with the sniffing framework.
Again: our goal should be to have an automated check for every potential objection to a pull request that we can push off human reviewers' plates, so I also support getting this into the CI build.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/Faaz8pV1R-4J.
I want to throw a bit of caution: like blue cheese, a code smell shouldn't necessarily break the build. I'd prefer to start small and build up the test suite incrementally.
Let's focus on getting the simplest possible test into our test suite, and then look to grow it.