Tasks 'Install Composer dependencies'/'Update active language' take a very long time

strarsis · November 17, 2017, 3:37pm

Trellis deploy needs a very long time for the tasks
"Install Composer dependencies" and “Update active language”.
How can I speed this up? The production server should have a fast internet connection, right?
Can I cache this somehow? Or is there a deploy command just for the assets/styles?

swalkinshaw · November 18, 2017, 5:14pm

Composer dependencies are “cached”. The vendor dir gets copied between deploys so it’s not like a full composer update install is happening from scratch every time.

Maybe run composer manually and see if some specific package is taking a while?

strarsis · November 18, 2017, 6:26pm

It could be caused by a more exotic setup where local git repository is cloned through a reverse SSH tunnel (I don’t want to host these git repositories on the public).

strarsis · February 7, 2018, 7:04pm

Follow up:
It is the wp core language update command in finalize-after site specific deploy hook that takes so long. Some caching would be really nice because it really takes a long time on each deploy.

wp core language install de_DE --activate alone wouldn’t suffice for installing the language files because it will only pull the core language files. For the plugins themselves, the language update command is necessary and has to run each time.

What is less of an issue is that during language update the plugin specific strings on live site is shown partially in English (fallback language) until all language files have been installed.

strarsis · March 8, 2018, 8:21pm

The languages/ directory can be added to project_copy_folders for having them copied in place. And they belong to this than rather to project_shared_children option because they are tied to a particular deploy (core version, plugins).

But what if the languages/ folder already contains files from the deploy, e.g. for overriding or adding (yet missing) plugin or theme translations? Then the folder won’t be copied and the one from the deploy is used, which doesn’t solve the issue.

github.com

roots/trellis/blob/f948df133c92cf13516c5f0cc00cdde773068e47/roles/deploy/defaults/main.yml#L14


# - you can set the git ref to deploy (can be a branch, tag or commit hash)
project_version: "{{ project.branch | default('master') }}"


# The source_path is used to fetch the tags from git, or synchronise via rsync. This way
# you do not have to download/sync the entire project on every deploy
project_source_path: "{{ project_root }}/shared/source"


# There are certain folders you'll want to copy from release to release to speed up deploys.
# Examples: Composer's `vendor` folder, npm's `node_modules`.
# These should not be part of project_shared_children since dependencies need to be atomic and tied to a deploy.
project_copy_folders:
- vendor


# All the templates to process on the remote system on deploy. These could contain config files.
# `src` and `dest` paths work the same as project_local_files.
project_templates:
- name: .env config
  src: roles/deploy/templates/env.j2
  dest: .env


# The shared_children is a list of all files/folders in your project that need to be linked to a path in `/shared`.

strarsis · March 17, 2018, 5:30pm

This approach seems to work well now, drastically reducing the deployment time when languages should be installed and also preserving site-specific language files (in site git repository). Also there is no short period of time during deploy anymore where the language falls back to default language (English).

roles/deploy/defaults/main.yml (at line 14):

# There are certain folders you'll want to copy from release to release to speed up deploys.
# Examples: Composer's `vendor` folder, npm's `node_modules`.
# These should not be part of project_shared_children since dependencies need to be atomic and tied to a deploy.
project_copy_folders:
  - vendor
  - web/app/languages

Add web/app/languages to project_copy_folders list.