Migrations doesnt check for exisiting table

[webcodecs]

Describe the bug I dont publish the migration cause of flexibility. You are using the publish command. The migrations will be executed on each deployment which is failing after the first deployment because the tables are already there.

Am i missing something?

To Reproduce Steps to reproduce the behavior:

1. Install package
2. Deploy package (a deployment is a complete new checkout and composer install)
3. Deploy package again

Expected behavior Deploying the application should not break.

I guess the problem is the new checkout on every deployment. The application does not know about the migrations in the Deployment before. Is there any possibility to disable package migrations if i publish them to my migration folder?

[chrispelzer]

That shouldn't be much of an issue to take care of. I'll look into it today.

[chrispelzer]

Reopening to talk about https://github.com/waynestate/nova-ckeditor4-field/pull/68#issuecomment-1301762349

@webcodecs I think I am confused about how your deployment flow is working and using the migrations.

You said you don't publish the migration but it is running on each deployment. That means that you don't have 2 migration under your applications database/migrations/ yet they are still being migrated?

You are not running php artisan vendor:publish --tag=nova-ckeditor4-field-migrations anywhere within your deployment? That's the only way I can see the migration running as a new migration everytime.

The only reason I am asking is because there is the Laravel option loadMigrationsFrom which will run the packages migrations when running just php artisan migrate due to package discovery, but I forgoed to more explicitly having to publish them. It sounds like that is happening but it isn't part of the package to do. https://laravel.com/docs/9.x/packages#migrations

[webcodecs]

Thanks for reopening!

Correct, i dont publish the migrations. The migrations will be executed every time out of the package. And this happend on every deployment. You publish the migration with a timestamp. Thats the reason why the app tries to migrate the migrations every time. After the first deployment there is an entry in the migrations table as follows:

2022_11_01_114604_create_ckeditor_attachment_tables

After the second deployment there is a additional entry: 2022_11_03_094450_create_ckeditor_attachment_tables

And on the next deployment there will be a new one. I hope you understand the problem

[chrispelzer]

@webcodecs

I think I see where this went wrong.

If you could take a look at #70 let me know if that can handle your situation. Using publishing, I should have set the date/time on the migration file itself to prevent your situation of additional "new" migrations. There is a config option now to use either or, but in the end the published migration date/time won't change.

[webcodecs]

I guess that should help and solve the problem :)

[chrispelzer]

@webcodecs Just released 1.2.0 with the new config options.