Magento 2, often a second deploy needed to work without errors

[Aquive]

Deployer Version

v7.3.1

Target OS

Debian

Which PHP version are you using?

PHP 8.1

Content of deploy.php or deploy.yaml

<?php
namespace Deployer;

require 'recipe/magento2.php';

// Config

set('repository', '<repo url>');
set('update_code_strategy', 'clone');
set('writable_mode', 'chmod');
set('keep_releases', 3);

add('shared_files', []);
add('shared_dirs', [
    'pub/feeds',
    'pub/blog',
    'pub/sitemaps'
]);
add('writable_dirs', []);

// Languages
set('static_content_locales', 'nl_NL');
set('magento_themes', [
    'Aqm/Luma',
    ]);
set('magento_themes_backend', ['Magento/backend']);
set('static_deploy_options', '--no-parent');
set('static_content_locales_backend', 'en_US nl_NL');
set('split_static_deployment', true);

// Hosts
host('production')
    ->set('hostname', '<host>')
    ->set('remote_user', 'app')
    ->set('deploy_path', '<path>');

// Hooks

after('deploy:failed', 'deploy:unlock');

Steps to reproduce

Very often we need to do a second deploy to make magento 2 working again after a first "succesfull" deploy. (The deploy is succesfull but Magento throws an erros, see below). I am not exactly sure when this problem occurs but I think it happens when enabling a previously disabled module.

This time it was this error. The CSP module was disabled, and with this deploy it was being enabled.

There has been an error processing your request
Warning: Undefined array key "policy_id"
in /vendor/magento/module-csp/Model/Collector/ConfigCollector.php on line 111

I just had another instance. I upgraded to 2.4.5-p10, after deploying one time it showed the older version. Deploying it again changed it to 2.4.5-p10. Was comming from (2.4.5-p9).

I'll tag @peterjaap already :)

PS: reopened as discussing since the issue was closed

[peterjaap]

I think you'll need to add the opcache recipe to clean your opcache on each deploy. See https://github.com/deployphp/deployer/blob/master/docs/contrib/cachetool.md

[Aquive]

@peterjaap thanks for your reply. Any idea why I need it? Sometimes It doesn't happen. Sometimes it does. All our clients are hosted at Hypernode. So the environments are the same. Not sure if I had these issues with earlier versions of Deployer...

[peterjaap]

No idea why in this particular case. However, you should always flush opcache after each deploy because opcache caches filepaths, but on each deploy new filepaths are generated by Deployer because the release dir gets a unique name. This causes the opcache to fill up with cached filepaths which are no longer used. When it's full, it won't cache any new files, so a new deploy may actually be slower than the old one because it's not opcached.

[Aquive]

@peterjaap Thanks. Tbh, I have never worried about caching etc when deploying with deployer in the past. Do I understand correctly that flushing opcache after each deploy is a best practice? If so, why isn't it incorporated in the Magento 2 receipe? Should it be incorporated?

[peterjaap]

That is definitely a best practice, if you use opcache. Not everybody does, so it's not part of the default recipe. The tools are there however, see https://github.com/deployphp/deployer/blob/master/docs/contrib/cachetool.md