setup Continous Integration about sharetribe HOT 13 CLOSED

i've connected my fork here: http://travis-ci.org/#!/elf-pavlik/sharetribe
fails at this moment but something to start with :)

from sharetribe.

i played bit more with it and now bundle install runs fine but fails on db:migrate, i guess need to do instead db:schema:load but enough for today :) http://travis-ci.org/#!/elf-pavlik/sharetribe

from sharetribe.

with few small changes now rake spec & rake cucumber run on travis-ci - both failing :)
http://travis-ci.org/#!/elf-pavlik/sharetribe/builds/2297350

@gnomet if you could get them both to green first, then i could next time i find time play with moving us to 1.9.3 #5
i'll try to catch you soon on irc (flowdock) to talk about your preferred git workflow...

from sharetribe.

Yep, I think it'll be good to update our gems up to date and then work for Travis compatibility. I remember that I tried it earlier and got stuck with sphinx... We have had thoughts of changing to Elastic Search (http://www.elasticsearch.org/) from Sphinx. Do you have any experience or opinion about these?

from sharetribe.

haven't tried elasticsearch, will take a look!

i guess for now we could try to see if we can get CI running without too much hassle and with what we have - sphinx
i would really like that we look for shortest path to get us on green there, then we can move stuff around with peace of mind ...

from sharetribe.

Yep, as soon as I get the migratino done to move our last ASI-using service to stand alone mode, I can simplify the test suite a lot. I could look at travis too at that point.

from sharetribe.

Now took a quick look at this once I got the bigger migration, and it was easy to get run the spec test (the default action) (still few failing there). You mentioned that you have put also cucumber in use, but I can¨t find your fork now at all.

from sharetribe.

@gnomet i had some problem with getting build triggered so i made this tmp repo to play with:
https://github.com/elf-pavlik/tmp-sharetribe-ci

from sharetribe.

@gnomet i just started preparing clean pull request from new fork that i made but i see you already started merging stuff from this messy old one ;) please note links in README which point to my temp repo!

from sharetribe.

since you enable API by default you can now remove from .travis.yml

- cp config/config.travis.yml config/config.yml

end related file from /config

from sharetribe.

Heh, sorry yea, in future working through pull requests is probably a better way. I just remembered you linking here as the place where you set up the cucumber to work too, and quickly looked through the changes and noticed the badge in readme but didn't spot the wrong link. :) Will fix that now.

And good point about config.travis.yml too. I was thinking that I need to look what are the differences and is there need for separate, but if it was only the api then good. :)

I'll do these changes to the develop, where I pulled your changes and in future I'll wait for pull requests before pulling. ;)

Btw. it seems cucumber tests encounter lot of timeouts: https://travis-ci.org/sharetribe/sharetribe/jobs/3491979 and that causes the suite to run over 25min and to be terminated. I can't yet see what causes the timeouts, but also didin't yet look in to that more.

from sharetribe.

now worries, my fault with forgetting to make a proper pull request already some time ago :)

i'll try to research those cucumber timeouts!

from sharetribe.

Travis setup has been there for a while (https://travis-ci.org/sharetribe/sharetribe) so I'm closing this issue.

from sharetribe.