The current e2e test setup has several issues. These changes are intended to fix some of them.
After starting the e2e_pgdb container with the database needs some time to complete initialization until it's ready to accept connections from the e2e_keys_api service. In my machine, the e2e_keys_api service always starts faster than the e2e_pgdb container completes its initialization. So, the e2e_keys_api service tries to connect to the DB in the e2e_pgdb container when it's not ready and always falls with a connection error.
It looks better to wait until the database in the e2e_pgdb container completes its initialization and only after that start the e2e_keys_api container. To implement this, the new health checker has been added to the docker-compose file for e2e tests. The implemented approach is pretty the same as described here
https://stackoverflow.com/questions/35069027/docker-wait-for-postgresql-to-be-running
The --env-file=./.env parameter in the test:e2e script in package.json is redundant, so, it has been removed. The docker-compose process can automatically recognize the .env file in the project root.
Hard-coded default DB name and credentials in the docker-compose file for the database container. As the database container with default setup works correctly only for the default database with default credentials, it doesn't make much sense to get these parameters from the .env file, because it's easy to misconfigure these parameters in the .env file for e2e tests. The idea is similar to the one introduced in this PR https://github.com/lidofinance/lido-keys-api/pull/267
The current e2e test setup has several issues. These changes are intended to fix some of them.
e2e_pgdb
container with the database needs some time to complete initialization until it's ready to accept connections from thee2e_keys_api
service. In my machine, thee2e_keys_api
service always starts faster than thee2e_pgdb
container completes its initialization. So, thee2e_keys_api
service tries to connect to the DB in thee2e_pgdb
container when it's not ready and always falls with a connection error.It looks better to wait until the database in the
e2e_pgdb
container completes its initialization and only after that start thee2e_keys_api
container. To implement this, the new health checker has been added to thedocker-compose
file for e2e tests. The implemented approach is pretty the same as described here https://stackoverflow.com/questions/35069027/docker-wait-for-postgresql-to-be-runningThe
--env-file=./.env
parameter in thetest:e2e
script inpackage.json
is redundant, so, it has been removed. The docker-compose process can automatically recognize the .env file in the project root.Hard-coded default DB name and credentials in the docker-compose file for the database container. As the database container with default setup works correctly only for the default database with default credentials, it doesn't make much sense to get these parameters from the
.env
file, because it's easy to misconfigure these parameters in the .env file for e2e tests. The idea is similar to the one introduced in this PR https://github.com/lidofinance/lido-keys-api/pull/267