I’m getting a strange error when my tests run on Heroku which wasn’t happening on Friday, everything is fine locally.
-----> Running test command `mix test`...
08:29:52.761 [info] Already up
08:29:53.389 [info] seeding in prod environment
08:29:53.389 [info] runing default seeds
All departments inserted
** (RuntimeError) cannot configure sandbox with pool DBConnection.Poolboy.
To use the SQL Sandbox, configure your repository pool as:
pool: Ecto.Adapters.SQL.Sandbox
(ecto) lib/ecto/adapters/sql/sandbox.ex:429: Ecto.Adapters.SQL.Sandbox.mode/2
(elixir) lib/code.ex:376: Code.require_file/2
(elixir) lib/enum.ex:675: Enum."-each/2-lists^foreach/1-0-"/2
(elixir) lib/enum.ex:675: Enum.each/2
(mix) lib/mix/tasks/test.ex:229: Mix.Tasks.Test.run/1
-----> test command `mix test` failed with exit status 1
I have updated it to in-dyno as after reading documentation it sounds like it is recommended for speed purposes, although I didn’t see it as being essential.
Updating to “in-dyno” has caused a new error on the test setup:
17:37:17.233 [error] Postgrex.Protocol (#PID<0.1220.0>) failed to connect: ** (Postgrex.Error) ssl not available
17:37:17.250 [error] Could not retrieve migrated versions. This error usually happens due to the following:
* The database does not exist
* The "schema_migrations" table, which Ecto uses for managing
migrations, was defined by another library
To fix the first issue, run "mix ecto.create".
To address the second, you can run "mix ecto.drop" followed by
"mix ecto.create". Alternatively you may configure Ecto to use
another table for managing migrations:
config :ev2, Ev2.Repo,
migration_source: "some_other_table_for_schema_migrations"
The full error report is shown below.
** (DBConnection.ConnectionError) connection not available because of disconnection
(db_connection) lib/db_connection.ex:934: DBConnection.checkout/2
(db_connection) lib/db_connection.ex:750: DBConnection.run/3
(db_connection) lib/db_connection.ex:1141: DBConnection.run_meter/3
(db_connection) lib/db_connection.ex:592: DBConnection.prepare_execute/4
(ecto) lib/ecto/adapters/postgres/connection.ex:86: Ecto.Adapters.Postgres.Connection.execute/4
(ecto) lib/ecto/adapters/sql.ex:256: Ecto.Adapters.SQL.sql_call/6
(ecto) lib/ecto/adapters/sql.ex:198: Ecto.Adapters.SQL.query!/5
(ecto) lib/ecto/adapters/postgres.ex:85: anonymous fn/4 in Ecto.Adapters.Postgres.execute_ddl/3
-----> test-setup command `mix ecto.migrate` failed with exit status 1
@outlog I really appreciate the assistance. I’ve updated the url in the test config. It seems strange they wouldn’t rename this one as “TEST_DATABASE_URL” as we are already using DATABASE_URL, by default, for production.
I’ll let you know how it goes. In the meantime, any suggestion which GH repo I should issue?
When a test run begins, you can use the database as normal via DATABASE_URL or REDIS_URL as appropriate. These urls will point to your locally installed database.
I don’t use heroku CI - so let’s figure out the issue first - if it continues to fail, maybe create a minimum github repo with one test - that fails to test on heroku CI - and I can give it a try…
only thing that pops out is that DB config - that really shouldn’t work against localhost…
13:21:49.770 [error] Postgrex.Protocol (#PID<0.1220.0>) failed to connect: ** (Postgrex.Error) ssl not available
13:21:49.775 [error] Could not retrieve migrated versions. This error usually happens due to the following:
* The database does not exist
* The "schema_migrations" table, which Ecto uses for managing
migrations, was defined by another library
To fix the first issue, run "mix ecto.create".
To address the second, you can run "mix ecto.drop" followed by
"mix ecto.create". Alternatively you may configure Ecto to use
another table for managing migrations:
config :ev2, Ev2.Repo,
migration_source: "some_other_table_for_schema_migrations"
The full error report is shown below.
** (DBConnection.ConnectionError) connection not available because of disconnection
And by this:
only thing that pops out is that DB config - that really shouldn’t work against localhost…
Did you mean my original config? shouldn’t work against localhost on my machine or against localhost against the Heroku test db?
Solved by ensuring the mix_env was set to ‘test’ in my app.json test scripts. I don’t know why that was fine beforehand, must be something to do with Heroku test changes.