Travis configuration?

[shawnacscott]

Any specific new configuration needed for Travis CI on this repo? I haven't configured it before, especially not with the Rails engine stuff going on.

[botandrose]

Yeah, testing this repo is kind of an open question. Right now I've copied just the Capybara acceptance tests over from calagator/calagator, as kind of a smoke test to ensure that the engine is mounted correctly, and nothing major is broken. However, this isn't ideal, because there's duplication between the two repos. I'd like to figure out a way to include and run the acceptance tests from the gem, but I have no idea if that's possible, or even really a good idea. Ultimately, we care about calagator.org itself working, so I don't think we can rely solely on the gem being well-tested...

In summary, more thought is needed here!

[botandrose]

I just realized I didn't really answer the question. :) I've already pared the Travis matrix down to a single test job, since calagator.org doesn't run on multiple dbs and multiple rubies, etc. However, Audrey has informed me that they actually run on sqlite in production, while the test is currently exercising postgres, so that needs to be updated to align with reality. Other than that I think we're good on Travis config for this repo.

[reidab]

When we deploy this new version, we may want to look at transitioning to postgres. I'd like to see both sqlite3 and postgres in the matrix for this repo for now.

[botandrose]

Hmm, I wonder if maintaining a matrix in this repo really makes sense? Either http://calagator.org is running on sqlite, or its running on postgres... its never running on both. I feel like this repo should just be whatever is actively deployed. Mostly for me, though, avoiding the matrix and other configuration variations was the main impetus for splitting off this repo, and what allows for it be so wonderfully simple (e.g. we can finally check in Gemfile.lock!). Meanwhile, the main calagator gem repo is still being thoroughly tested on all rubies and and dbs, so we continue to have assurances that we're not regressing.

How about instead adding a PR to this repo with the db switched to postgres? That would still give us travis runs for that db, and can be merged in and deployed once you're ready to make the switch. What do you think?

[reidab]

Agreed 👍