On 10/4/12 12:09 PM, [MA]Pascal wrote:
Lukas,
Sure I can help.
You don't need much memory (not more than 1G) the only problem is the
extra time PHPunit needs to do the coverage process.
Testing Symfony is already quite long, so making it slower is probably a
bad idea. And adding code coverage slows things down a lot. Furthermore,
I don't see the need to build the code coverage for every push. What
about just running code coverage in a cron job each day. I can setup
that quite easily and publishing the result on symfony.com should then
become trivial.
Uploading the result of the coverage is one thing but how can we trace
it inside the travisci build ? I mean how to link the build to the
webpage of the coverage.
Do we need to store history of the coverage or we only need a static
repo (coverage.symfony.com) with the very last successfully uploaded
coverage result ?
Another question : do you know if it's possible to generate coverage
using the merge of multiple PHPUnit processes ? I explain myself : you
can have specific testCase for PHP5.4 which would be covered only in the
5.4 travis-ci job but won't be in the others, so those classes won't
have their 100% coverage even it's covered overall.
Pascal.
Le jeudi 4 octobre 2012 09:50:17 UTC, Lukas Smith a écrit :
Aloha,
Met up with Josh from Travis-CI yesterday and learned that there is
now support for repo level secrets. Furthermore I think there should
be sufficient memory to generate code coverage and other metrics. If
not then soon there will be an upgrade to the OSS VMs to bump the
memory to 3-4GB which should then definitely be enough.
This means it should become possible to generate code coverage docs
on travis-ci and then upload them to some server. Note that the
secret isnt available for PR's as it would then be possible to
output the secret in a PR test run. The secret obviously can only be
decoded on a single repo (ie. symfony/symfony) and we could then
write a little script that only does the generation for specific
branches (2.0, 2.1, master ..).
I could help coordinate the implementation of this, but I probably
dont have time to do the actual scripting.
@Pascal: do you have an interest to work on this?
@Fabien: it would be useful for either me or the person taking over
the implementation to have admin permissions. Semi-related it seems
like travis-ci depends on someone logging into travis-ci.org
<http://travis-ci.org> every now and then to get an up to date admin
token.
regards,
Lukas Kahwe Smith
[email protected] <javascript:>
PS: If anyone has questions about travis-ci, including the pro
version for private repos feel free to contact me.
PPS: I dont have any financial relationship to travis-ci, I just
like their services and how they are helping the OSS community
--
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
--
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
