chore(tests): report code coverage to scrutinizer #11395
Conversation
jeabakker
force-pushed
the
code-coverage
branch
from
659e7b4
to
4bffc4c
Compare
|
I have configured scrutinizer to run it's own tests. This will just add a few minutes of processing to already heavy build process |
|
we're also working on speeding up the tests. I think it's easier to manage all tests from one place |
|
I am not sure how much faster the tests can be without migration to in-memory sqlite. Even then, reliability of tests is questionable without proper process isolation. I got sqlite working, but we need to drop all raw SQL for it to be of any use. There will be a PR coming soon refactoring all ege* to OO query building, which can then be used to rewrite all other queries. I won't manage it all alone, so if you want to help with that it might be better use of time that trying to speed up tests |
|
If you are not interested, I have already forked Elgg, so I will be diverging and doing my own thing. |
|
our first focus for speeding up the test is moving to local images for seeding, the current Faker site is slowwwwwww |
|
We probably don't even need images there, can be moved to an options array similar to metadata and populated only for on-site seeding. IMO, not needed for Travis builds |
|
That's how long it took to run the job with code coverage report: 49 min 57 sec The ultimate problem is that code coverage requires xdebug, which is heavy on composer and everything else. |
|
Did you back up scrutinizer config before making changes? I have spent quite a lot of time putting it all together, and now it's just barebones. |
|
I didn't make the changes but here is the backup https://gist.github.com/jeabakker/d7f7f03967e6a1f05974f9ab6a4fb8e8 |
|
Could you update scrutinizer please, I need to see the code coverage report. Re: builds. One option is to eliminate seeding entirely on the upgrade build. We could create a MySQL dump of a seeded vanilla 2.3 install and data for and just import those during Travis build. The idea is to test the migration, so burning cycles on 2.3 seeding makes little sense from the testing standpoint |
|
codecoverage on scrutinizer has been restored for the time being |
jeabakker
force-pushed
the
code-coverage
branch
from
e37700d
to
4bffc4c
Compare
|
we need to merge this... scrutinizer resources are too little for good progress... maybe actual runtime is indentical, but it takes ages for scrutinizer to free up resources before the job starts |
|
At least do it during e2e build, no reason to add a separate job |
|
Merging this... can combine with other job later... lets see how this goes... waiting on scrutinizer is a pain, so we need to speed things up |
|
You need to update scrutinizer config |
|
I updated the scrutinizer config according to https://scrutinizer-ci.com/docs/tools/external-code-coverage/ |
No description provided.