Use ignore settings of the target storage if the config ignore config is ignored

Yes this is on purpose 🐛 Use ignore settings from storage being transformed if they exist Fixed Because otherwise you can not deploy it at the same time as a change to the config ignore settings.

However this doesn't work if you are ignoring the config ignore settings too. So there is still something we should do.
Now if we would check the settings in the target storage (ie when importing the config that would be the active site config) and if the config ignore config is ignored then we use that instead this would solve the issue for you. But then it wouldn't work any more on export as you are expecting and you would have to make config ignore not ignore the config ignore config on exporting (ie not use the simple mode). Which would mean that you can configure it to behave the way you want, but at the expense of being a bit more difficult to understand the nuanced configuration.

Just for clarification: You do ignore the config ignore config right? otherwise the first deployment would set it back and the next one would create the same problem for you.

Thanks for the fast response.

You do ignore the config ignore config right?

Yes, it is in the ignored configurations.

Exporting ignored configurations is not a concern in the use case I'm facing: The only issue I faced was when importing config, and a new configuration to ignore was added directly on a website, which had not been done in quite a while.

Also, I had overlooked 🐛 Use ignore settings from storage being transformed if they exist Fixed as unrelated to the situation, so thanks again for bringing it to attention.

If I understand you correctly, changing the storage used when determining which config to ignore would fix the behavior to what I was expecting?
Is this something that would be possible to change on a per-site basis, at the settings level?

No this wouldn't need to be configured at a environment specific settings level.
If you ignore the config ignore config it should just take the one that it is going to then ignore anyway. so if you set your site to do so then you effectively say "I am managing the config ignore settings per site and not through configuration management".

Updated the code to look for destination config ignore settings and if that config is there in destination then will ignore the configs added in destination. Please review. If there are some suggestion please let me know.

Thanks for the MR!
However the approach in the code is wrong. We already have a way to know if some piece of config is ignored or not, so we should re-use that.

You touched even the code that creates the ConfigIgnoreConfig object by reading from a config storage, we need to create another one and ask it if the config ignore settings are ignored for updating and if so we use that object instead of the ones currently created.

And this is quite a big change, so we definitely also need a test for it.

Hi @bircher, I'm bit confused should we change the implementation or should we add test here?

it needs a test and it also the code/implementation needs to be completely changed.

Hi I have a similar problem because current module version has different behaviour on import than the previous one.

On 8.2.x

My admin interface ignored:
webform.webform.*
and is aligned with the confing_ignore.settings.yml.

Imagine I want to make a deployment where I change an specific weborm.
I would go to admin interface I would add the exception there without doing any kind of drush cex only admin interface.

So looks like
Admin interface:
webform.webform.*
~webform.webform.contact_us
But confing_ignore.settings.yml. still has
webform.webform.*
Then, on the deployment there is is a drush cim command that
detect 2 changes and updates them
webform.webform.contact_us
config_ignore.settings.yml

So after the deployment I have webform.webform.contact_us changes applied and the admin interface reverted to only
webform.webform.* and aligned again with config_ignore.settings.yml

With version 8.3.x seems that is not possible any more because it looks to transformation_storage

Maybe its only a question to point always to ConfigIgnoreConfig::fromConfig($this->configFactory->get('config_ignore.settings'));

Son changing:

if ($transformation_storage->exists('config_ignore.settings')) {
      try {
        // This can be used to hook into config ignore via an event subscriber
        // which alters the data prior to the config ignore subscriber.
        $settings = $transformation_storage->read('config_ignore.settings');
        $ignoreConfig = new ConfigIgnoreConfig($settings['mode'] ?? 'simple', $settings['ignored_config_entities'] ?? []);
      }
      catch (\InvalidArgumentException $exception) {
        // We should probably log this exception.
      }
    }
    if (!isset($ignoreConfig)) {
      $ignoreConfig = ConfigIgnoreConfig::fromConfig($this->configFactory->get('config_ignore.settings'));
    }

By
$ignoreConfig = ConfigIgnoreConfig::fromConfig($this->configFactory->get('config_ignore.settings'));

@aheredia, I have encountered the same problem with 'config_ignore.settings' being present in the ignore list. The issue arises when we add 'config_ignore.settings' to the list of ignored configurations and it should not revert during drush cim.

Therefore, I have included 'config_ignore.settings' in the config ignore array. Now, both drush cim and drush cex are functioning properly, and if 'config_ignore.settings' is present in the ignore list, it does not revert back.

The patch from #13 does not do what I asked in #9 and it doesn't have tests.
Without tests, the issue will have to remain "needs work".

Also please if you are considering contributing to this issue, do not manipulate the ignored settings without a ConfigIgnoreConfig because doing so will inevitably be wrong.