I think 3) sismo, well there has been some work with sismoFinder and some Sismo automation git hooks etc, automation of PR testing sounds very interesting and I will add it to TODO tasks, unless someone has a template already (and yes i am against fabpot intent to keep sismo unextensible). i think a dev/personal solution has to always remain active, if symfony2 ships with sismo for dev POV, man it will rock even more. And i have not said anything about how it plays nicely with behat, phpspec, and whatnot config tools as shown here http://www.craftitonline.com/2011/09/sismo-setup-as-personal-ci/
well I am biased, big fan of sismo, I understand symfony2 ci is another thing, but just trying to speak aloud for the community side that wants to always have integration-friendly code and automation besides the great tools like jenkins (java) and brothers, and the new kid on the block Travis which as you said will have some limitations anyway as it will become a paid service perhaps in the future for fancy stuff. anyone having a startup of a template to autotest PRs on sismo, please message me, I am so eager and interested ... thanks! On Thu, Nov 17, 2011 at 12:27 PM, Lukas Kahwe Smith <m...@pooteeweet.org> wrote: > Hi, > > Its clear that Symfony2 needs a CI server. I think there is no dispute on > this point. > > Here is an overview of the features I think are critical: > 1) testing on different PHP versions and operating systems > 2) getting code coverage reports > 3) automated code quality metrics like PHP_CodeSniffer and PHP_Depend > 4) testing of PRs > > Options: > > 1) Custom Jenkins (eventually available at http://ci.symfony.com/): > At this point the only viable server for this seems to be a custom Jenkins > setup, which Pascal is already working on. Afaik we also have servers > available to test not only on *nix but also on Windows. This is still a work > on progress, but its also time consuming and will require continued > attention. Such a setup will cover 1), 2) and 3), but supporting 4) will > likely be beyond the scope of what is reasonably possible for us to maintain. > > 2) Travis CI (eventually available at > http://travis-ci.org/#!/pborreli/symfony): > This service was just launched and is therefore much more limited in terms of > features so right now it only covers 1) but limited to *nix. However once > symfony supports travis 4) will be as easy as going to travis-ci.org, logging > in via github.com and clicking a single button to enable testing of user > forks. The big benefit is that after the initial setup > (https://github.com/symfony/symfony/pull/2664) there is effectively nothing > we have to do to keep this running. So if at all it will serve as a fallback. > To see an example build check http://travis-ci.org/#!/pborreli/symfony > > In the future travis-ci will also get the ability to generate at least a > limited number of artifacts. Most likely code coverage reports and maybe even > PHP_CodeSniffer and PHP_Depend, but it will likely also remain more limited. > It might eventually also support other operating systems, but this seems a > bit more down the road. > > One feature that is likely to appear soonish is automated testing of PR's. > This means that the user will not have to do anything to enable testing if > they dont want to. Instead as soon as the PR is send, travis-ci will > automatically run the tests and somehow add the information if the current > state of the PR is passing all the tests to the PR (f.e. via a comment). This > will mean at this point 4) will be fully automated > > 3) Sismo (run locally) > In order cover 4) aka to be able to tests PRs users can also install Sismo to > automated building. This however will mean a bit of setup work, it will also > eat resources on the users machine and it will require manually updating the > PR to state if the tests pass or not. > > Conclusion: > > At this point there does not seem to be an alternative to 1). However 2) > seems to add very important features that 1) cannot offer. In the long run it > might even be able replace 1) or at least handle some aspects of 1) which > will mean that we will need less physical and human resources to keep our own > Jenkins running. > > So at this point I recommend going with both 1) and 2) .. of course users are > also free to use 3) as part of their development. > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
