Bug: Table created on "migrate --pretend"

Hi

I have a Postgresql database where tables are located in different schemas, and I would like to have migrations for tables in (some of) these schemas.

In the Laravel database config file I have created 2 entries pointing to the same Postgresql database but to different schemas - public and tli (my test schema). Currently I have 3 migrations:

1. create_users_table
2. create_password_resets_table
3. create_hardware_table

The first 2 are the "built-in" migrations and they create tables in the (default) tli schema. The third migration needs to create a table in the public schema, so it explicitly references the pgsql_public connection:

public function up()
{
    Schema::connection("pgsql_public")->create('hardware', function (Blueprint $table) {
        $table->increments('id');
        ...
        $table->timestamps();
    });
    DB::Statement("
      INSERT INTO public.hardware (<list of fields>) 
        SELECT * FROM public.some_other_table
    ");
}

That is all well and good, and it works. I can run the commands php artisan migrate and php artisan migrate:reset and the tables get created, populated with data, and dropped as expected.

TLI-MBP:OPDB thomaslindgaard$ php artisan migrate
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table
Migrating: 2018_01_24_220840_create_hardware_table
Migrated:  2018_01_24_220840_create_hardware_table

TLI-MBP:OPDB thomaslindgaard$ php artisan migrate:reset
Rolling back: 2018_01_24_220840_create_hardware_table
Rolled back:  2018_01_24_220840_create_hardware_table
Rolling back: 2014_10_12_100000_create_password_resets_table
Rolled back:  2014_10_12_100000_create_password_resets_table
Rolling back: 2014_10_12_000000_create_users_table
Rolled back:  2014_10_12_000000_create_users_table

However, if I run php artisan migrate --pretend it prints out the SQL for the first 2 migrations and the statement for populating the hardware table with data. But it does NOT print the create statement for the hardware table. Instead it executes the SQL and creates the table (no data is copied). If I run the migrate reset command it says that there is nothing to rollback which is correct, and it does not touch the hardware table.

TLI-MBP:OPDB thomaslindgaard$ php artisan migrate --pretend
CreateUsersTable: create table "users" (<fields>)
CreateUsersTable: alter table "users" add constraint "users_email_unique" unique ("email")
CreatePasswordResetsTable: create table "password_resets" (<fields>)
CreatePasswordResetsTable: create index "password_resets_email_index" on "password_resets" ("email")
CreateHardwareTable: INSERT INTO public.hardware (<list of fields>)
            SELECT * FROM public.some_other_table

TLI-MBP:OPDB thomaslindgaard$ php artisan migrate:reset
Nothing to rollback.

If I then run php artisan migrate I get an error saying that the hardware table already exists.

So in short: It seems like migrations using Schema::connection(<some schema>)->create() break the php artisan migrate --pretend command and create the tabels anyway.