Roots Discourse

Theme deployment (shared host & capistrano) – am I doing it right?

Hello (again),

I am on a shared host. Before, my Sage 9 theme deployment with bedrock-capistrano worked fine. After updating to Sage 10.0.0.beta1 I had to fix other issues and haven’t tried deploying until yesterday… and I have some problems… or maybe just questions :wink:

In the docs: theme deployment it says that I have to run composer install on the server and copy over the generated dist/ folder. My deploy script (config/deploy.rb) did include both tasks (pastebins: composer install & upload dist folder), and I assumed it should still work fine as it worked in Sage 9.

First, I realised that in Sage 10 there is no dist/ folder, right now it’s named public/ and the deployment created another release, but it was incomplete – but this was an easy fix in the deploy script.

Then, I had another error which happened after composer install:

  ...
  Your lock file does not contain a compatible set of packages. Please run composer update.
  Problem 1
  - ext-psr is present at version 0.6.1 and cannot be modified by Composer
  - symfony/service-contracts v2.5.0 conflicts with symfony/service-contracts v2.5.0.
  - symfony/service-contracts is locked to version v2.5.0 and an update of this package was not requested.

I’ve tried the typical: removing composer.lock & vendor/, running composer update on the server, same locally, then deploying again… no good. And I was not sure about the PSR version and was confused by the weird symfony package conflict.

I thought “maybe it needs to update, not install”, so I modified my aforementioned composer install task from the deploy script to execute composer update instead of composer install – guess what, now the deployment finishes with no errors! I noticed that this command actually does perform installation of packages after updating them:

/usr/local/php74/bin/php /usr/local/bin/composer update
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 1 update, 0 removals
 - Downgrading symfony/service-contracts (v2.5.0 => v2.4.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 60 installs, 0 updates, 0 removals
- Installing brick/math (0.9.3):...
...
(and so on)

Back to the point: am I doing it right?

  • Since composer update actually installs packages, can I assume that this is somewhat the correct way of deploying the theme?
  • If I am wrong, and I should be executing composer install then perhaps the PSR extension should be updated on the server? Right now it’s at version 1.2…

I am aware that the documentation is being updated… so I am really doing stuff by trial & error.

If anyone got through this lengthy post, and can advise, please let me know.
Thank you!


Some earlier issues that I ran into, maybe someone will find it useful.

  1. Didn’t update theme folder in the config/deploy.rb script (doh!), this is essential but apparently can be overlooked… therefore, obviously:
    set :theme_dir, 'theme_folder'

  2. At some point I saw this error during deployment:
    psr/container 1.1.2 requires php >=7.4.0 -> your php version (7.3.32) does not satisfy that requirement.
    I definitely made sure that the domain PHP version is set to 7.4, logged in via SSH and apparently the shell was still using 7.3, so I’ve added an alias for the php command in .bash_profile to be using 7.4…but this didn’t help.
    I finally learned that when you run commands over SSH it uses so called non-login shell. In your deploy config script you can map a command to be using correct paths:
    SSHKit.config.command_map[:composer] = "/usr/local/php74/bin/php /usr/local/bin/composer"
    You can check PHP version in non-login shell by running ssh my-server.com 'php -v'.

No.

You should not be running composer update on deploy. To do so defeats the point of using composer to create reliable deploys Dependencies shouldn’t be updated when you deploy, since that has the potential to introduce bugs/problems.

I’m not familiar with ext-psr but if it’s part of the server and not managed by Composer, then you should probably ask your host about it.

1 Like

Thank you @alwaysblank for going through my lengthy rant, and the clarifications!

This time I have double checked that the deploy script is executing correctly with all the proper paths and so on… But for no particular reason I am getting that PSR extension error exactly after composer install is executed from the theme folder, and there is no error (or warning) when I run the same command on the remote theme path…

Frankly, it seems that Sage doesn’t require PSR specifically, so maybe it must NOT be there?

I guess I will have to rely on deploying via FTP for now…


I think I managed to fix the problem… probably a more seasoned dev would think about this instantly…

  • I’ve checked via SSH what are the .ini files used by PHP: php --ini
  • since I can’t modify a (probably) shared php.ini file, I created my own without the PSR and Phalcon extensions
  • then in the capistrano deploy script I instructed PHP to use that php.ini using -c argument: SSHKit.config.command_map[:composer] = "/usr/local/php74/bin/php -c /home/bzx/projects/myproject/php.ini /usr/local/bin/composer --no-ansi --no-dev --no-interaction --no-progress --optimize-autoloader --no-scripts --classmap-authoritative"

The hosting company didn’t yet respond about the PSR extension, but I’ve found out that other hosting companies do not load this extension, and found a discussion on extension’s GitHub page that it may cause issues.

Anyway, a small success. Nothing feels better than writing about your problems and then writing about how you fixed them :wink:

Feel free to unlist this thread, but maybe someone will find it useful.
Thanks, I’ll be quiet for some time now :wink: