Hi. Here the scenario:
- My dev and staging environment have a module "module_X" enabled + exactly the same config files in conf/sync + an entity name to ignore (like "module_X.settings" for example)
- I want to uninstall "module_X" on both environment, because i don't need it anymore
- So i will first uninstall the module in dev via a
drush pmu module_X + remove the config_ignore rule specific to module_X via UI + drush cex -y. It will delete the config files related to the module and update the config files core.extension + config_ignore.settings
- Everything is good. But now i want to deploy these config files to my staging environment to reflect the same changes, in our case, we want everything to be done automatically, an auto-uninstall of "module_X" with the help of the config files
- I do my GIT stuff or whatever to bring the files on the staging environment. And i run a
drush cim -y, and here what i get:
[error] Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization. in Drupal\Core\Config\ConfigImporter->validate() (line 728 of /vagrant/web/core/lib/Drupal/Core/Config/ConfigImporter.php).
[error] The import failed due to the following reasons:
Configuration <em class="placeholder">module_X.settings</em> depends on the <em class="placeholder">module_X</em> module that will not be installed after import.
The problem here, it seems, is that the active config_ignore rules are not aware than the rules related to "module_X" are not there anymore in the new config_ignore.settings file. And because config_ignore go through his normal process when a rule of the active config is matching, and so keep/force the dependence whatever the situation of a module and if it's an import or an export.
It's updated too late in the whole process, all the updated config files are imported in the same time, "module_X" is still not really uninstalled so it probably not possible to match some condition with that.
It doesn't seems there is some 'pre-import' possibility stuff.
A quick way to do that in local (deploy like):
drush en module_X + add the ignore rule for module_X via UI + drush cex -y- manually: remove "module_X" from core.extension + delete the config files related + remove the related rule from config_ignore.settings
- run a
drush cim -y
My suggestion would be for this specific config file containing the rules (currently config_ignore.settings), to always override the active config with what is in the file, if the file exists.
But being not an expert of the Config API, i absolutely don't see how to do that directly via the config_ignore module for now, and if it's at least possible.
I try to see a scenario where doing that could create problems or side effects, but i don't see for now.
The only workaround i've founded for this now is to:
- manually update the config_ignore rule on staging via UI before the
drush cim -y (not really convenient for an automated deployment)
- run a
drupal cis --file="/config/sync/config_ignore.settings.yml" before the drush cim -y
More globally, it should be possible to change the way the code play, following you are doing an import (config files trusted) or an export (config active trusted). The sources and the way to manage it in a reliable order are not the same in some situations. But i supposed that it's not only related to this module!
