Moving myself to the committers section

[maco]

I'm a committer now.

[coveralls]

Coverage remained the same at 84.18% when pulling c5fbda0 on maco:dev into f830ed1 on Growstuff:dev.

[pozorvlak]

Looks like the build's failing because we're trying to start ElasticSearch using sudo, which isn't supported by the container-based build system we're using. We'll need to fix up travis.yml to require sudo when testing with ElasticSearch.

[oshiho3]

It's very strange. I thought the sudo warning message were harmless based on this issue with Travis CI: travis-ci/travis-ci#3044
Also the warning message has been there before and still all the tests were successful. hmm

Yet this time, I can see errors related to availability of Elasticsearch service as below.

Failure/Error: expect(page).to have_css "h1", text: "Crop search"
       expected to find css "h1" with text "Crop search" but there were no matches. Also found "Elasticsearch::Transport::Transport::Errors::ServiceUnavailable in CropsController#search", which matched the selector but not all filters.

Also I just pushed #728 and the Travis passed all the tests for me.

Very strange as there is nothing obvious with this pull request that can affect Elasticsearch. I don't know how reliable Travis is but it may worth rebuilding Travis-CI.

[maco]

Also I created the pr and it passed, then I noticed the pr was changing
schema.rb (unintended) so I backed out the schema.rb change, and then it
failed.

On Fri, May 22, 2015, 12:28 AM Shiho Takagi notifications@github.com
wrote:

It's very strange. I thought the sudo warning message were harmless based
on this issue with Travis CI: travis-ci/travis-ci#3044
travis-ci/travis-ci#3044
Also the warning message has been there before and still all the tests
were successful. hmm

Yet this time, I can see errors related to availability of Elasticsearch
service as below.

Failure/Error: expect(page).to have_css "h1", text: "Crop search"
expected to find css "h1" with text "Crop search" but there were no matches. Also found "Elasticsearch::Transport::Transport::Errors::ServiceUnavailable in CropsController#search", which matched the selector but not all filters.

Also I just pushed #728 #728
and the Travis passed all the tests for me.

Very strange as there is nothing obvious with this pull request that can
affect Elasticsearch. I don't know how reliable Travis is but it may worth
rebuilding Travis-CI.

—
Reply to this email directly or view it on GitHub
#742 (comment).

[oshiho3]

@maco, I noticed recently that parent_id column has been added to the posts table in schema.rb but this column addition doesn't have the corresponding migration. To confirm this, I just dropped the database in dev, deleted schema.rb file and ran rake db:migrate. The newly created schema.rb doesn't have the parent_id column.

This may be something totally unrelated to the Travis CI error, but I'm wondering this may cause database inconsistency in future. All the tests completed successfully without this column anyway according to the Travis result from your initial commit. So I wonder the column may have just got in by accident and we actually should get rid of it?

By the way, do you want to try re-running Travis CI and see it may by chance run successfully? Here I found how to do it.
http://stackoverflow.com/questions/17606874/trigger-a-travis-ci-rebuild-without-pushing-a-commit

[maco]

After re-running it, it turned green. twilight zone music

On Fri, May 22, 2015 at 10:20 AM Shiho Takagi notifications@github.com
wrote:

@maco https://github.com/maco, I noticed recently that parent_id column
has been added to the posts table in schema.rb but this column addition
doesn't have the corresponding migration. To confirm this, I just dropped
the database in dev, deleted schema.rb file and ran rake db:migrate. The
newly created schema.rb doesn't have the parent_id column.

This may be something totally unrelated to the Travis CI error, but I'm
wondering this may cause database inconsistency in future. All the tests
completed successfully without this column anyway according to the Travis
result from your initial commit. So I wonder the column may have just got
in by accident and we actually should get rid of it?

By the way, do you want to try re-running Travis CI and see it may by
chance run successfully? Here I found how to do it.

http://stackoverflow.com/questions/17606874/trigger-a-travis-ci-rebuild-without-pushing-a-commit

—
Reply to this email directly or view it on GitHub
#742 (comment).

[oshiho3]

nice :)