Deploy.yml does `composer install` not `composer update`

trellis
1

Note: this was a self-solved problem. I’m leaving this here regardless, in case others get the same confusion as me. See next post for my answer.

I’m currently managing the plugins of a particular site with specific versions (not wildcards) in composer. This has allowed me to match the exact versions of plugins that are running on the current live installation of the site, while I prepare the new trellis version.

The problem I’m having is that when I bump the version number in composer.json, then run deploy.yml, the new version doesn’t get installed, because the playbook runs composer install, and of course, this command only installs what is in the lock file. What I’d like is composer update, which would look for new versions in the json file, and install those instead.

Thinking about it, I guess composer install might be a better default, because lots of projects will use wildcards, and we really only want wildcard versions to be bumped manually, when we’re around to see what the effects are.

However, in my case, I’m specifying exact version numbers, so I’m happy for my automated deployment process to go ahead and update to new versions. It’s kind of bugging me that I have to ssh into the server and do composer update manually… I want a “one click” operation.

Could we perhaps have an optional setting in Trellis, where deploy.yml runs composer update instead?

2

After further thought, I’ve realised the answer is simple.

You always run composer update on your dev environment (and only your dev environment).

This installs the new plugins locally, and creates a new composer.lock file - which you can then commit to your repo. Thus, the next time you deploy to staging or production, there is no need to run composer update - the lock file is already updated, and the automatic composer install is sufficient.

Running composer update locally has the additional benefit that you can test the site locally before committing your new .json and .lock to the repo. I like this, because ideally, I want each commit to leave the project in a working state. I don’t want to have to commit first and then test on some remote server before realising something was wrong. Of course, there may be bugs you don’t spot immediately in dev, but at least you can check your changes haven’t done something drastic like bringing the site down.

6 Likes