Travis and D8 CMI

[mikemadison13]

It seems odd to me that the default travis behavior doesn't sync configuration beyond the blt setup:drupal:install command. On several projects now I've had to override this default behavior to also then run blt local:update so that stored configuration is imported (particularly so that Behat tests will pass). Does it make sense to include local:update as part of the default Travis / build process so that it doesn't have to be overwritten?

[grasmash]

I don't quite understand. I had thought that setup:drupal:install did import all local config. Why would it need to be done again?

[mikemadison13]

it def. loads "something" but not everything.

if you take a look at https://travis-ci.org/Drupal4Gov/Drupal-GovCon-2017/builds/175178452 this build failed and then look at https://travis-ci.org/Drupal4Gov/Drupal-GovCon-2017/builds/175198787 this one passed. Literally the only thing that changed was adding blt local:update into the build process.

On my local when I did a clean install, I saw it "load" the configuration, but it didn't actually seem to do anything with it...

I see "create" actions being taken all throughout the config as part of the blt > setup:config-import: step, but still the end result isn't the desired one (the config doesn't make it into active configuration)

[mikemadison13]

BTW:

When I do a clean install and it runs the setup:config-import step, then I immediately run blt local:update, this happens:

$ blt > setup:update:

There are no changes to import. [ok]
The following updates are pending:

user entity type :
The user.field_company_organization field needs to be installed.
The user.field_first_name field needs to be installed.
The user.field_industry field needs to be installed.
The user.field_last_name field needs to be installed.
The user.field_motivation field needs to be installed.
The user.field_number_of_cons field needs to be installed.
The user.field_role field needs to be installed.
Do you wish to run all pending updates? (y/n): y
Cache rebuild complete. [ok]
Finished performing updates. [ok]
There are no changes to import. [ok]
Cache rebuild complete. [ok]

which leads me to believe that the CMI is somehow staged but not actually fully imported.

[grasmash]

Can you experiment a bit with modifying setup:Drupal:install to make it work alone?

[mikemadison13]

Yeah, it looks like we should be able to modify setup.xml to include a blt setup:update directly after blt setup:install so that the process just includes the update hook. It's already IN the setup.xml file as a matter of fact, it just isn't called from anywhere (which is odd).

See https://github.com/acquia/blt/blob/8.x/phing/tasks/setup.xml#L238

[grasmash]

Actually, we already do this. See https://github.com/acquia/blt/blob/8.x/phing/tasks/setup.xml#L170.

[mikemadison13]

I reviewed the BLT repo and found that the problem seemingly is that the setup:update code was added to BLT in the last few days, it wasn't at the project level. I have patched BLT at the project level and am now experimenting with that current version of the setup script. I'm hoping that resolves the issue. Will advise.

[grasmash]

I've merged #674 to address this. Please let me know if it is not resolved.