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 [email protected] -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
