We were having problems under certain conditions with Travis and
Knapsack where tasks were still being loaded twice and so they were
being executed twice.
When we insert a record in PostgreSQL and we specify the ID, the
internal ID sequence for that table isn't updated.
In order to keep the original IDs so we didn't break any foreign keys,
we specified the IDs when copying the table, resulting in a table having
its ID sequence with a value of an existing record. When trying to
insert a new record, we got a `PG::UniqueViolation` exception.
Updating the sequence after the data migration might not be the most
elegant solution, but it's easy to do and it's already been tested on a
production environment.
We'd rather keep the table so future data migrations work smoothly, so
we change the migration in order to create the translation table without
using models.
Calling `load_tasks` in several files made rails load the tasks several
times, and so they were executed several times when called.
Since the milestone migration can't be executed twice in a row (it would
fail with duplicated ID records), loading the tasks several times made
the milestone migrations task specs fail.
Generalize the BudgetInvestmentStatus model to Milestone::Status so it
is not specific to budget investments, but can be used for any entity
which has milestones. This is in preparation to make the Milestone
model polymorphic and usable by entities other than budget investments.
Resetting sessions and driver is automatically done by requiring
'capybara/rspec', as shown by the (lack of) that configuration for RSpec
in the Capybara README, manual testing of those settings, and Capybara's
code itself.
Using `find_each` ignores the scope order we set in `Widget::Card.body`,
and since we don't expect to have thousands of cards, using batches
isn't necessary.
This way we remove the "WARN Scoped order and limit are ignored, it's
forced to be batch order and batch size" message we were getting in the
specs.
Make sure we create the Poll::OfficerAssignments in the same order the
booth_assignments where previously created. So the spec "Poll::Shift
officer_assignments creates and destroy corresponding
officer_assignments does" not fail.
