search

acquia / drupal-environment-detector

Provides common methods for detecting the current Acquia environment
GNU General Public License v2.0
10 stars 12 forks source link

Check for ACSF update environments also. #17

Closed lpeabody closed 3 years ago

lpeabody commented 3 years ago

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 the config-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:

  1. Generate an artifact with BLT.
  2. Do a "Code and databases" deployment on the test environment.
  3. Allow the update to complete.
  4. View the logs for a site that runs on the above-mentioned split. Check for drush cim log output stating the modules in the split were uninstalled.
  5. Also view in the logs that the modules were re-installed during the 2nd import.
lpeabody commented 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...