orchestral/testbench

SQLSTATE[HY000] [2002] Connection refused

Closed this issue · 18 comments

  • Testbench Version: 7.12.1

Description

Hi,

After I got the updated testbench version, I can not execute some commands successfully.
For example, the following command throwing the error SQLSTATE[HY000] [2002] Connection refused.

vendor/bin/testbench migrate --database=sqlite --path=vendor/orchestra/testbench-core/laravel/migrations --path=../../../../database/migrations

I have set my own testbench.yaml file with the following database configuration but it seems that testbench-core ignores them.

DB_CONNECTION="sqlite"
DB_DATABASE="database.sqlite"

How can I set the DB_CONNECTION parameter in testbench-core ? Is it possible to change the default configuration settings of testbench using any commands option?

Seems like you haven't create the database file, on the latest version you can use

php vendor/bin/testbench package:create-sqlite-db

Seems like you haven't create the database file, on the latest version you can use

php vendor/bin/testbench package:create-sqlite-db

Still same. Using the above, I just get the extra following message

File [database/database.sqlite] already exists ..................... SKIPPED

I have set my own testbench.yaml file with the following database configuration but it seems that testbench-core ignores them.

both of the configuration are the default.

I have set my own testbench.yaml file with the following database configuration but it seems that testbench-core ignores them.

both of the configuration are the default.

From what I see, the default db connection is mysql

Screenshot from 2022-12-06 15-49-30

When you run vendor/bin/testbench it would generate .env from .env.example, which is default to sqlite. You can confirm this by running php vendor/bin/testbench about

When you run vendor/bin/testbench it would generate .env from .env.example, which is default to sqlite. You can confirm this by running php vendor/bin/testbench about

Please find below the output of the mentioned command. I am still getting mysql

Screenshot from 2022-12-06 16-03-33

image

Unable to replicate your issue.

When you run vendor/bin/testbench it would generate .env from .env.example, which is default to sqlite. You can confirm this by running php vendor/bin/testbench about

From what I see when I run vendor/bin/testbench is that it would generate .env from .env file which is located in my project root directory and not from .env.example which is into testbench-core package.

image

Unable to replicate your issue.

Is there any other way to change the default db connection into testbench-core ?

From what I see when I run vendor/bin/testbench is that it would generate .env from .env file which is located in my project root directory

Then you don't you just edit that file directly?

From what I see when I run vendor/bin/testbench is that it would generate .env from .env file which is located in my project root directory

Then you don't you just edit that file directly?

I am trying to figure out in a different way and avoid dependencies between my .env file and testbench-core.
Since the package also copies the testbench.yaml file, why does it not take it into consideration?

Nope, .env has higher priority than testbench.yaml

DB_CONNECTION=sqlite php vendor/bin/testbench about has highest priority

Nope, .env has higher priority than testbench.yaml

Is there any way to skip /bypass the .env file through the commands options and take into consideration the testbench.yaml settings?

We not going to allow that.

We not going to allow that.

Hello again,

Can I ask if it's probable solution two merge the two files (.env + testbench.yalm) and give priority to testbench configuration ? For example, if common variables exist in these files (like DB_CONNECTION,DB_DATABASE), then to prioritize what testbench.yaml has setted.
Is that possible? The aim here is not to skip .env but to overwrite common variables.

This takes place also in other cases like with phpunit.xml which its settings override and change the default config of the environment variables.

No plan to modify the behavior. Use what's available at the moment.