Search code examples
phplaravelgoogle-app-enginegoogle-cloud-sql

How to run Laravel migrations on Google App Engine Standard after Deployment


I´m using Laravel 8 with Google App Engine Standard (GAE) and Google Cloud SQL. The connection between App Engine and Cloud SQL works (tried it with a simple DB::query in a controller), so everything seems to be set up correctly.

BUT: I want to run "php artisan migrate" after I´ve deployed the Laravel App to GAE. So I tried to add the following to my composer.json:

"post-install-cmd": [
    "@php artisan migrate  --no-interaction --force",
    "@php artisan cache:clear"
]

However, when I deploy the app the following exception is thrown when the migrate command runs:

In Connection.php line 678:
                                                                               
  SQLSTATE[HY000] [2002] Connection refused (SQL: select * from information_s  
  chema.tables where table_schema = forge and table_name = migrations and tab  
  le_type = 'BASE TABLE')                                                      

As you can see it uses the db "forge" which is the default fallback value in Laravel for the environment variable "DB_DATABASE". So it looks like the env_variables set in app.yaml are not loaded when composer runs the post install method which also results in a missing database Host. So that´s the reason for the "connection refused" exception.

Do you have any idea how I can address that issue so that the correct environment variables are loaded when composer runs the migrate command?


Solution

  • I know it's a late answer, but I think the reason you're running into this for a variety of reasons.

    1. Google Cloud Build does not have access to the same environment variables that the appengine standard runtime has.
    2. Cloud build and the appengine runtime do not run the traditional php-cli tools that can run artisan commands. Maybe someone else can point out if I'm outdated on this. I've tried running artisan commands via a route before and it doesn't work.

    We just run them locally against the prod db. Not the greatest, but hopefully that helps.