Forge is not running my migrations in my deploy script
When I push to deploy via github webhook or click the deploy now button on Forge, Forge does not refresh and seed my migrations, as I I have in my deploy script. Any tips to debug?
//deploy script
cd /home/forge/default
git pull origin laravel
composer install --no-interaction --prefer-dist --optimize-autoloader
echo "" | sudo -S service php7.2-fpm reload
if [ -f artisan ]
then
php artisan migrate:fresh --seed
fi
//lastest deployment log
Thu Nov 29 20:50:29 UTC 2018
From github.com:biniyam17/NextDorm
* branch laravel -> FETCH_HEAD
724045b..c57435f laravel -> origin/laravel
Updating 724045b..c57435f
Fast-forward
database/migrations/2018_11_29_072740_create_log_events_table.php | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.
Nothing to install or update
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
Discovered Package: [32mbeyondcode/laravel-dump-server[39m
Discovered Package: [32mfideloper/proxy[39m
Discovered Package: [32mlaravel/tinker[39m
Discovered Package: [32mnesbot/carbon[39m
Discovered Package: [32mnunomaduro/collision[39m
[32mPackage manifest generated successfully.[39m
**************************************
* Application In Production! *
**************************************
Command Cancelled!
Laravel is protecting you from running your migrations as you are in production.
**************************************
* Application In Production! *
**************************************
Command Cancelled!
You have your script doing
php artisan migrate:fresh --seed
This will reset your production database everytime your deploy which i suspect isnt what you want.
Try replacing with
php artisan migrate --force
This will run any new migrations that have not been applied since your migrations were last applied.
If you actually what to fully reset your database on each deploy just add --force to your script (but really know what your doing before taking this option!!!)
migrate:fresh drops all the tables and runs through the up methods, which is something you typically don't want to do on your production database; hence your command getting canceled. You can SSH into your server and run the command manually if you want to (it will ask for verification if you do this in your production environment).
If you just want to update the database with new tables or changes, php artisan migrate should suffice.
Edit: like @D9705996 pointed out, the --force flag is needed regardless if your environment is set to production.
@nash - you need the --force flag in production even if you are just doing migrate (this is from my local machine in production mode)
php artisan migrate
**************************************
* Application In Production! *
**************************************
Do you really wish to run this command? (yes/no) [no]:
>
Yeah, thanks --force was what I needed it. I am using a test server so the seeding and refreshing isn't a problem.
@nash It turns out php artisan migrate isn't enough through the deploy script. But it sounds like you were suggesting it would be enough through the ssh environment.
As a further point, do you suggest always having --force in my deploy script so any new migrations always get run or just adding --force when I know a deployment will include a new migration, and then take --force out of the script?
I would leave --force in the script. if there are no new migrations you will get
php artisan migrate --force
Nothing to migrate.
There is also a package that you can use to check if there are new migrations which could be useful if you need to do something different in your deploy depending on if there are migrations
It seems the default deployment script uses php artisan migrate --force...it just slipped my mind as I rarely run that command manually on the prod server.
