Test for schema changes to stored config

[danepowell]

There's currently a major gap in the CM process that I've brought up a few times, such as here (last paragraph) and here. Basically, whenever a contributed module has a schema update (made through update hooks), that update needs to be baked into any relevant config in the codebase (whether in Features or core config). Unfortunately it's all too easy to forget to check for this when updating modules, so an automated test for this would be ideal.

The challenge is that there's no way for a test to know whether a given feature is overridden intentionally (due to a code change) or unintentionally (due to a db change, i.e. schema update). One solution is to check for overrides after a db update, and fail tests if db updates are performed and a feature is overridden afterwards. This would have the side effect of basically forbidding db updates and features changes in the same PR.

[danepowell]

I've toiled with this problem for several hours now, and I'm fairly convinced that it's impossible to prevent via automated tests. The problem is simply that we have two "canonical" sources of config. Database update hooks consider the database to hold the canonical configuration reference, while we would prefer to think of Features or core CM files on disk being the canonical reference. If both of those change at the same time, there's no way a machine can know which changes are correct. The best idea I could come up with would be to somehow force database updates to be applied to configuration files on disk as well. But it's hardly a foolproof solution, and feels pretty hacky.

Whatever solution exists to this problem, I think it's going to have to involve a massive rearchitecture of CM in Drupal.

In the short term, developers simply need to be aware that this problem exists and need to make sure that configuration changes get exported to disk whenever modules are updated. Using the no-overrides feature from #841 will aid with this (having clean features means that a developer can simply check if any features are overridden after running database updates).

[danepowell]

I think the additional documentation in the features workflow doc (soon to be configuration workflow) is the best we can do for now.