Cache Flush At Wrong Place

[sprankhub]

This is specifically about the Magento 2 recipe, but I saw that the cache flush is at the same spot for most of the recipes, so it might be an issue for more recipes... This is how the deployment tree looks like for Magento 2:

$ vendor/bin/dep tree deploy
The task-tree for deploy:
└── deploy
    ├── deploy:prepare
    │   ├── deploy:info
    │   ├── deploy:setup
    │   ├── deploy:lock
    │   ├── deploy:release
    │   ├── deploy:update_code
    │   ├── deploy:shared
    │   └── deploy:writable
    ├── deploy:vendors
    ├── deploy:clear_paths
    ├── deploy:magento
    │   ├── magento:build
    │   │   ├── magento:compile
    │   │   ├── magento:sync:content_version  // before magento:deploy:assets
    │   │   └── magento:deploy:assets
    │   ├── magento:maintenance:enable-if-needed
    │   ├── magento:config:import
    │   ├── magento:upgrade:db
    │   ├── magento:maintenance:disable
    │   └── magento:cache:flush
    └── deploy:publish
        ├── deploy:symlink
        ├── deploy:unlock
        ├── deploy:cleanup
        └── deploy:success

As you can see, the Magento cache is flushed as part of deploy:magento, when the new release is prepared. So the cache is flushed when the current symlink still links to the old release. Only in the next step deploy:symlink, the symlink is switched to the new version. When you have a lot of requests on your system, there will most probably also be a request between the magento:cache:flush task and the deploy:symlink task. This means the cache will, after it has just been cleared, directly be filled with old data again. This regularly leads to issues to us, so that we manually need to run a cache flush after deployment manually. This fixes the issue to us:

after('deploy:symlink', 'magento:cache:flush');

So, my question is, shouldn't the Magento cache be flushed after the symlink has been switched to the new version? Am I missing something?

By the way, this issue is neither an OPcache issue nor fixed with the magento:set_cache_prefix task.

Ccing the active Magento Deployer people: @Schrank @peterjaap @schmengler @wilfriedwolf

[schmengler]

you're probably right @sprankhub

we didn't have issues because our pipeline contains a post-deploy step where the cache is cleaned too, but it would make sense to have it done properly by deployer.

nor fixed with the magento:set_cache_prefix task.

that means, magento:cache:flush at the current point already uses the new cache prefix, but still the old code base?

[sprankhub]

Thanks for your feedback!

This is how the tree looks like when you use the cache prefix tasks:

$ vendor/bin/dep tree deploy
The task-tree for deploy:
└── deploy
    ├── deploy:prepare
    │   ├── deploy:info
    │   ├── deploy:setup
    │   ├── deploy:lock
    │   ├── deploy:release
    │   ├── deploy:update_code
    │   ├── deploy:shared
    │   ├── magento:set_cache_prefix  // after deploy:shared
    │   └── deploy:writable
    ├── deploy:vendors
    ├── deploy:clear_paths
    ├── deploy:magento
    │   ├── magento:build
    │   │   ├── magento:compile
    │   │   ├── magento:sync:content_version  // before magento:deploy:assets
    │   │   └── magento:deploy:assets
    │   ├── magento:maintenance:enable-if-needed
    │   ├── magento:config:import
    │   ├── magento:upgrade:db
    │   ├── magento:maintenance:disable
    │   └── magento:cache:flush
    ├── magento:cleanup_cache_prefix  // after deploy:magento
    └── deploy:publish
        ├── deploy:symlink
        ├── deploy:unlock
        ├── deploy:cleanup
        └── deploy:success

It shows that during the creation of the "next" release, the cache prefix is used. However, when the "next" release becomes the current one, it uses the old cache prefix again.

[peterjaap]

Heh, I think you're right. I just checked our customizations for our pipelines (which are on top of this recipe) and I see we have this in there too;

after('deploy:symlink', 'magento:cache:flush');
after('deploy:symlink', 'cachetool:clear:opcache');`

[sprankhub]

Thanks for the feedback!

Would you agree that we can move the magento:cache:flush task from within the deploy:magento task to after the deploy:symlink task? There shouldn't be any need to flush the cache twice, if I am not mistaken.

[peterjaap]

Correct!

[sprankhub]

Okay, so here we go: #3883