Closed justinlevi closed 5 years ago
@danepowell - any thoughts on what I'm doing wrong here?
Potentially related:
Note, I can get the same behavior with the standard installation profile as well, or at least seemingly related. I've been reading through all the BLT docs on configuration management and I'm pretty sure I'm following the recommended "Best Practice" approach to getting started.
After creating a new BLT site w/ (lightning), running $ drush cex
, what's the next step I should take in order to ensure the next $ blt drupal:install
will run without issue?
One thing worth mentioning is that based on the "Using the Configuration Installer with Lightning" blog post above, the permissions on settings.php
should be set to 444 - which I have verified.
The drupal/config_installer
is included with lightning so that shouldn't be an issue. The problem seems to be that BLT by default uses the following command on pipelines:
blt setup --define drush.alias='${drush.aliases.ci}' --environment=ci --no-interaction --ansi --verbose
This is a problem because blt setup
runs the robo command drupal:install
which in turn calls $ drush site-install
using the blt.yml defined profile name. If I'm understanding the config issue, drush si
needs to use "config_installer" instead of lightning, right?
Again, based on the blog post by @danepowell above, if you're using config_installer, you need to be using
$ drush site-install config_installer
instead of $ drush site-install lightning
on subsequent runs.
I can verify that BLT is using the profile > name defined in blt.yml when doing the setup by adding -vvv
to $ blt setup -vvv
A few additional notes though. Setting permissions on settings.php to 444 doesn't seem to do anything. Each time you run $ blt setup
, the lightning installation profile ($settings['install_profile'] = 'lightning';
) gets added.
Things I'm trying:
config_installer
which should run the $ drush si
using the config_installer instead of lightning. drush cex
again which gives me the following:Update (HACKY WORKAROUND??) - The following seems to be working:
config_installer
in blt.yml` $settings['install_profile'] = 'lightning';
in settings.php (again...)This can't be the correct approach though right?
Thanks for reaching out, @justinlevi. I'm trying to replicate this now; will update with what I see.
I haven't gotten through your entire post yet, but just based on the configuration files that you reported as differing, I think you are hitting this core bug: https://www.drupal.org/node/2915036
Try applying the patch there and re-exporting configuration.
@danepowell I'll read through that issue more thoroughly but does that apply if I'm running 8.57?
Also, this is literally a new project via:
$ composer create-project --no-interaction acquia/blt-project my-project
as of yesterday
Yes, that patch will work with 8.5.x. This is a core bug, not a BLT bug, so it'll happen regardless of how you create the project.
Assuming that works, it might be worth adding to BLT. I know we don't want to be in the habit of patching core, but this one issue just generates so much noise.
I ran the same composer create-project...
process to set up a new core 8.5.7 site and I do see the same issue, and with the exact same files.
When I did a second round of drush cex
, committed those, and then reinstalled I did not have the problem recur.
@ba66e77 Yeah, I think I got to the same conclusion. Any idea why the second round of drush cex
is required? This is a bug then right, or does this extra step just need to be documented?
@danepowell The patch you mentioned doesn't seem to impact anything as far as I can tell.
This is almost certainly a result of the core bug I linked to. Let me guess: if you do a git diff after the second config export, the only thing that changes is that a field gets added to the hidden region? That's the core bug.
I don't know if all of the patches in that issue are created equally. I use this one: https://www.drupal.org/files/issues/2018-03-23/2915036-68.patch
If you apply that patch prior to installing Drupal the first time, then when you export configuration it should match the second export you did previously, i.e. with the fields correctly in the hidden region.
The core issue should explain this pretty thoroughly. If not, please let me know how I could make it clearer.
Following these steps I cannot reproduce the issue:
"patches": {
"drupal/core": {
"config": "https://www.drupal.org/files/issues/2018-03-23/2915036-68.patch"
}
},
composer update
blt setup
drush cex
blt setup
again.@justinlevi any updates on if this is still an issue, given @danepowell's PR above?
@mikemadison13 Unfortunately, we still run into this quite a bit. Config with D8 and BLT causes issues on our team regularly.
both the standard profile in core and lightning use hook_install
which makes them incompatible with installing from config (see https://www.drupal.org/node/2897299).
@justinlevi you might have better luck with the config_profile or config_distro modules which leverage config filter plugins to accomplish this with config splits. Presumably you will be installing drupal in a hosting environment where workarounds with sync / settings.php will be difficult or not possible without write access to the file system and settings.php or additional custom code, so the linked modules have worked well for their respective use cases.
closing due to inactivity
This is still super busted. I really wish BLT, Drupal Config, and Pipelines would work together harmoniously. Our team has wasted hundreds of hours trying to work through this issue.
Of course, every time we do this, before we run it, I have to remove the UUID from shortcut.set.default.yml because, for some reason, BLT doesn't understand that entities won't exist in a new site.
i usually recommend disabling the config check if this issue persists, you can have issues with that too, but it avoids this issue neatly:
cm:
allow-overrides: true
cm:
uuid: ####################################
# Possible values: core-only, config-split, features, none.
allow-overrides: true
core:
path: ../config
configkey: sync
dirs:
# Corresponding value is defined in config.settings.php.
sync:
path: sync
configkey: vcs
dirs:
# Corresponding value is defined in config.settings.php.
sync:
path: default
install_from_config: false
features:
allow-overrides: true
So, I tried doing my best to merge the blt install configuration and the actual site's configuration and that seemed to allow Pipelines to pass. Of course, cim on the server failed, so I had to go into the UI and check the differences between the configs there and those that were staged for import. I rolled back my local repo made adjustments to the config one at a time, basically changing the uuids to the ones being used on the server or removing the uuids entirely from the yml files.
After that, the only other thing I had to do was change my sync variable to point at the vcs folder in my global settings file.
/**
* Set configuration directories
*/
$config_directories = array();
$config_directories['sync'] = $app_root . '/../config/default';
$config_directories['vcs'] = $app_root . '/../config/default';
And, here are the files that need their UUIDs removed every time we export the configuration and try to run BLT setup:
- shortcut.set.default.yml
- system.site.yml
- field.storage.node.body.yml
you should leave the UUID in system.site. BLT uses that UUID to rewrite your site UUID during config import to avoid a lot of these issues.
Well, when I remove the UUID from that file, BLT runs fine and pipelines passes. When I don't remove it, I get a "configuration does not match" error.
When I look at the configuration UI in dev and prod, they have the exact same UUID as the yml file when I export config. BLT just doesn't want anything to do with it.
After creating a brand new project, with no configuration exported. I then install drupal and do a config export. The next time I run $
blt drupal:install
I get the error:Configuration in the database does not match configuration on disk
This is a brand new install and the prior step was to export the config so this seems like a bug to me. This is also causing pipelines to fail the build artifact as well.
My system information:
Output of
blt doctor
:When I run this command:
I get the following output:
And I expected this to happen:
I expect Drupal to install and the config to import without an error.