use StyleCI

[Lukas Kahwe Smith]

Aloha,

I have enabled StyleCI on many of my OSS projects.
We also enabled it on Jackalope / PHPCR related repos.

What do you think about adding it to all Symfony CMF repos as well?
IMHO it would safe us and contributors a lot of time and I think its also not so annoying to receive CS nitpicks from a machine, than it is from a human.

https://styleci.io

I would use the “symfony” preset.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[David Buchmann]

sounds good to me

[Daniel Leech]

Me also.

On Fri, Oct 30, 2015 at 09:32:52AM +0100, David Buchmann wrote:
> sounds good to me
>
> --
> You received this message because you are subscribed to the Google Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Lukas Kahwe Smith]

> On 31 Oct 2015, at 10:29, Daniel Leech <dan...@dantleech.com> wrote:
>
> Me also.
>
> On Fri, Oct 30, 2015 at 09:32:52AM +0100, David Buchmann wrote:
>> sounds good to me

I guess we should do this after having merged all the key PRs for the next RCs as otherwise we will end up with lots of merge conflicts on open PRs which is annoying to deal with. Worse yet, in non rebased PRs there will be confusion when the PRs fail or when they do not yet have the “symfony” CS rule set loaded.

So once we are ready for RCs, I will enable style CI, so that we can get those issues fixed with minimal hassle for contributors.

[Maximilian Berghoff]

looks nice and important, but why not using Codsniffer on travis?

[Lukas Kahwe Smith]

> On 06 Nov 2015, at 12:41, Maximilian Berghoff <maximilia...@gmx.de> wrote:
>
> looks nice and important, but why not using Codsniffer on travis?

because they can automatically propose what needs to be fixed. also this way you see if the tests pass .. ie. CS violations do not break the build.

regards,
Lukas

[GMX - Maximilian Berghoff]

Sure, but normally i want the build to break, when CS is not valid. Same
for MD as done by scrutizer.

[Zander Baldwin]

I'm assuming that StyleCI is free for open-source, so sure, have both (Travis and Style) since there's not exactly a down-side.

Aside from the points everyone is making (CS on Travis will fail entire build on standards violation, Style propose code improvement suggestions):

• Splitting testing across two services will speed things up as you aren't putting the entire load on Travis CI. In theory, the webhooks should complete quicker. Not really that important, but I do find myself staring at PR pages waiting for checks to pass or fail, when I'm procrastinating my next task.
  Running all tests on each for redundancy is another option should anyone think it necessary.
• I have CodeSniffer integrated into my IDE and find that it doesn't pick up on every coding standards infraction - StyleCI's (and Scrutinizer CI's) analysis is way better and much more in-depth.
  

[Lukas Kahwe Smith]

well the PR still “breaks” just with a separate notification.
so when looking at the PR I can see at a glance that the tests are passing but CS is failing .. and then with a few clicks a PR for that PR can be created to fix the CS violations.

[gmx Privat]

Is there a Kind of a config file, which i can use in my IDE (what i currently do) and styleCI is able to read? When yes, then it would ne nice to commit such a file. Or simple Symfony2 as standard?

[Lukas Kahwe Smith]

> On 06 Nov 2015, at 14:45, gmx Privat <maximilia...@gmx.de> wrote:
>
> Is there a Kind of a config file, which i can use in my IDE (what i currently do) and styleCI is able to read? When yes, then it would ne nice to commit such a file. Or simple Symfony2 as standard?

https://github.com/Soullivaneuh/php-cs-fixer-styleci-bridge

[Daniel Leech]

So I guess the consensus is "yes" and this is actionable?

On Fri, Nov 06, 2015 at 12:03:29PM +0000, Zander Baldwin wrote:
> I'm assuming that StyleCI is free for open-source, so sure, have both
> (Travis and Style) since there's not exactly a down-side.
> Aside from the points everyone is making (CS on Travis will fail entire
> build on standards violation, Style propose code improvement suggestions):
>

> * Splitting testing across two services will speed things up as you

> aren't putting the entire load on Travis CI. In theory, the webhooks
> should complete quicker. Not really that important, but I do find
> myself staring at PR pages waiting for checks to pass or fail, when
> I'm procrastinating my next task.
> Running all tests on each for redundancy is another option should
> anyone think it necessary.

> * I have CodeSniffer integrated into my IDE and find that it doesn't

> pick up on every coding standards infraction - StyleCI's (and
> Scrutinizer CI's) analysis is way better and much more in-depth.
>
> On Fri, Nov 6, 2015 at 11:46 AM, Lukas Kahwe Smith
> <[1]sm...@pooteeweet.org> wrote:
>
> > On 06 Nov 2015, at 12:41, Maximilian Berghoff

> <[2]maximilia...@gmx.de> wrote:
> >
> > looks nice and important, but why not using Codsniffer on travis?
>
> because they can automatically propose what needs to be fixed. also this
> way you see if the tests pass .. ie. CS violations do not break the
> build.
>
> regards,
> Lukas
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to [3]symfony-cmf-de...@googlegroups.com.
> For more options, visit [4]https://groups.google.com/d/optout.

>
> --
> You received this message because you are subscribed to the Google Groups
> "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to [5]symfony-cmf-de...@googlegroups.com.
> For more options, visit [6]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:sm...@pooteeweet.org
> 2. mailto:maximilia...@gmx.de
> 3. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 4. https://groups.google.com/d/optout
> 5. mailto:symfony-cmf-de...@googlegroups.com
> 6. https://groups.google.com/d/optout

[Lukas Smith]

yes

regards,
Lukas

> To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Daniel Leech]

Made a prototype PR for the Routing component:
https://github.com/symfony-cmf/Routing/pull/159

[Daniel Leech]

I have pushed styleci branches to all the CMF repos, and enabled the
styleci service on them.

Next step will be making the PRs and setting the class headers -- which
I think must be done individually on each repository atm.

Will try and do this tomorrow.

[Daniel Leech]

As you may have noticed, I have now made PRs on all the CMF repos. It
remains only to review and merge them.

Please have a look if you are the maintainer of a CMF repository and
merge if you are happy.

Unless there are any objections, I will review and merge them all in
anycase on Friday.

[Maximilian Berghoff]

Do we the chance to test that styleCI stuff localy as i used to Do it with phpcs or any other linter/stylechecker? Maybe as a storm plugin, a git hook or a executable? The reason is: it is a bad feeling to get that late (in PR) notice of a fail.

[Daniel Leech]

Not currently. You need to either use the PR feature of StyleCI or download the
patch and:

git apply ~/Downloads/patch.txt
git add whatever
git commit --amend
git push origin foo_branch -f

On Thu, May 19, 2016 at 02:27:41PM -0700, Maximilian Berghoff wrote:
> Do we the chance to test that styleCI stuff localy as i used to Do it with phpcs or any other linter/stylechecker? Maybe as a storm plugin, a git hook or a executable? The reason is: it is a bad feeling to get that late (in PR) notice of a fail.
>

[gmx Privat]

Actually i whant to get to know the fail before i push. So that is not really optimal.
What was the point against using scrutinizer with phpcs/md. We can share come Symfony Style Configs and can run it localy.