Problems with environnement variables with Forge/Envoyer

Did you get this figured out? The issue is that you don't have the right credentials for the forge user. First, check to ensure you are actually using the env variables in you app/config/database.php file. Here's mine as an example (ignore the options line as that's specific to my app). Also, see my comment for DB_PASSWORD:

        'mysql' => [
            'driver'    => 'mysql',
            'host'      => env('DB_HOST', 'localhost'),
            'database'  => env('DB_DATABASE', 'forge'),
            'username'  => env('DB_USERNAME', 'forge'),
            'password'  => env('DB_PASSWORD', ''), //<- is this your problem? The second param is the default if no env variable is set
            'charset'   => 'utf8',
            'collation' => 'utf8_unicode_ci',
            'prefix'    => '',
            'strict'    => false,
            'options'  => [PDO::MYSQL_ATTR_LOCAL_INFILE => true],
        ],

If that's all good, post the DB_ portion of your .env here -- just subsittute phony info for your real credentials exactly as you have tem in your .env file. Again, here's mine with dummy credentials:

DB_CONNECTION=mysql
DB_HOST=localhost
DB_DATABASE=myappsdb
DB_USERNAME=forge
DB_PASSWORD=myappspassword

@lindstrom

Hi, after a little chat with Taylor Otwell, it appears that one of the problem was that I set my DB_HOST to the ip adress of my server. Taylor told me to set it up to localhost... in his word :

« Forge does see the environment variable. MySQL is just saying that because you’re connecting to it from localhost. Set your environment variable to local host. »

After that the problem persist for the day, but this morning it seems to have resolve itself (maybe the config take some time to update on the server side)

But now I get this error when I try to deploy the code from Forge

SQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default value for 'created_at' (SQL: create table users (id int unsigned not null auto_increment primary key, first_name varchar(50) not null, last_name varchar(50) not null, email varchar(100) not null, bio varchar(500) not null, slug varchar(100) not null, password varchar(255) not null, remember_token varchar(100) null, created_at timestamp default 0 not null, updated_at timestamp default 0 not null) default character set utf8 collate utf8_unicode_ci engine = InnoDB)
[PDOException]
SQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default value for 'created_at'

Which also make no sense to me because I use the default users table that comes with Laravel out of the box, and, on my local machine, it works well.

Side note : Since you know I used envoyer, it is worth mentionning that no warning come up when I deploy with envoyer, the migration seem to fail silently.

Also, I dont understand why I should set my db_host to localhost and not the ip adress of the server (has Jeffrey Way did in the Forge tutorial), but it worked so I can live with that ;)

Thanks for your time btw, it is appreciated.

Also, I dont understand why I should set my db_host to localhost and not the ip adress of the server

Effectively the server has two IP addresses - it's main IP address and 127.0.0.1/localhost. You can see this for yourself by running the ifconfig command from the shell.

The MySQL server will probably be set to only listen on 127.0.0.1/localhost, so any connections to the main IP address will be ignored. Make sense?

You aren't using env in production are you? The env file is not meant for a production site. from the dotenv github page:

Usage Notes

When a new developer clones your codebase, they will have an additional one-time step to manually copy the .env.example file to .env and fill-in their own values (or get any sensitive values from a project co-worker).

phpdotenv is made for development environments, and generally should not be used in production. In production, the actual environment variables should be set so that there is no overhead of loading the .env file on each request. This can be achieved via an automated deployment process with tools like Vagrant, chef, or Puppet, or can be set manually with cloud hosts like Pagodabox and Heroku.

See the part:
phpdotenv is made for development environments, and generally should not be used in production. But if not, just wanted to point this out. And the above is from the author of the .env, Taylor didn't write / program that.

Hi, the MySQL was a dumb mistake on my part, I am pretty to this sort of thing and the error was because on MySQL 5.7 you need to use a valid default timestamp. You can’t insert 0s.

I didn't understood the error at first because on my developpement machine, I use a older version of MySQL.

Now everything is working fine, I just add to replace the timestamps by $table->nullableTimestamps(); in the migration files.

@jlrdw

I am using Envoyer to set the environnement variables, It uses the .env file I think

What do you suggest exactly?

Isn't it the kind of tool suggested by dotenv ?

« This can be achieved via an automated deployment process with tools like Vagrant, chef, or Puppet, or can be set manually with cloud hosts like Pagodabox and Heroku »

I wasn't suggesting anything. I would hard code the DB connection, and sensitive data in the actual config files, not in the env file.

@nztim

Yeah I understand now, but do you know where in the config I can see which address MySQL listen to?

It's in the MySQL server configuration file my.cnf, probably located in /etc/mysql

bind-address            = 127.0.0.1