2. Clearly defined and easy to implement pushing code updates to site repository

[krook]

No description provided.

[krook]

Questions:

• What is a common example of a site update? What files change?

[krook]

Any change to

• Drupal
• Installation-wide themes/modules (/var/www/modules and /var/www/themes)
• Site code (/var/www/sites)

The /sites/default/files directory would be exclusively for user-generated content and would change on the mounted directory rather than triggering a build and redeploy.

[krook]

All of drupal/* from the tarball is moved to /var/www/ on base NGINX and PHP image builds.

For Drupal code updates there's a two-phase build:

• Need a script that can be invoked to rebuild the base Drupal image (based on a given new semver, invoked manually or through a committed file), then relayer on top anything that's custom.
• That, in turn, will trigger a custom code rebuild on top (see below), along with a rolling deploy.

For custom code there's a one-phase build:

• When anything changes in the following folders, trigger a versioned rebuild of all three images, along with a rolling deploy.
  • code/modules
  • code/themes
  • code/sites

/var/www/html/sites/default/files is overlayed at start time from the shared read/write volume so doesn't need a rebuild.

/var/www/html/sites/default/settings.php is currently copied from /root/template.settings.php at runtime, but should instead come from the code/sites folder.

[krook]

Currently exploring the following approach:

For Drupal (and NGINX/PHP updates):

• A file checked into the config/ directory with a semver version number (for Drupal) and Docker image version will trigger base image builds and custom code build and deploys.

For custom code:

• Any code checked into code/ will only trigger the additional layer build and deploy.