Closed lpeabody closed 3 years ago
Hm, after re-reading the deployment process documentation, I'm not entirely sure that the environment detection is the issue that is causing the behavior I'm seeing. The documentation claims that the update process takes place entirely on the idle production (non-update) environment, so the split detection should work fine...
I'll close this while I continue to investigate. If I come back to the same conclusion then I'll open this back up again...
Motivation
ACSF has update environments such as 01update (live), 01devup, 01testup, etc...
During the update process, I was seeing modules for the test environment get uninstalled unexpectedly. The only explanation I could come up with was that the split that controlled these modules was not having its status overridden to enabled on the environment.
I'm not completely aware of ACSF's underlying workings, but ultimately I would see these modules get reinstalled by the time the update process completed, but they should have never been uninstalled in the first place. I'm also not sure why the modules would get reinstalled, since the process running the update seems to have taken place entirely in the update environment.
I am using BLT 12.8.2 with the standard
drupal:update
call running off of theconfig-split
strategy, which runs config import twice. The first time import runs the split modules get uninstalled, and the 2nd time it runs the split modules get installed.Proposed changes
Add pattern matching to also detect the update environments that run ACSF deployments.
Testing steps
Assuming you have an ACSF application with a config split for the 01test environment (
config_split.config_split.stage
) which also has some modules included in its configuration:drush cim
log output stating the modules in the split were uninstalled.