* var/page_cache as writable_dirs
It will fix following Zend exception after successful deployment:
Fatal error: Uncaught Zend_Cache_Exception: cache_dir "/path/to/www/releases/7/var/page_cache" is not writable in /path/to/www/releases/7/vendor/magento/zendframework1/library/Zend/Cache.php:209
This exception does not occur on every environment, it depends on PHP pool user/group (default www-data or owner of project directory).
* docgen
* Use correct Git ref spec when `sub_directory` is specified.
The bug is described in detail in issue #3137.
* change variable name for sub-directory target (as requested in PR)
* Add curly braces to domain in Caddyfile
Adding curly braces after the domain name, allows for multiple deploys in the same server.
* regenerate doc for docs/recipe/provision/website.md
Co-authored-by: Victor van Herpt Valdivia <victor@vhvLaptop.lan>
* Update to the lock recipe so that it shows you who currently has the lock on the deployment
* DD#0000: feat: Updated joy test
* DD#0000: feat: Regenerated docs
* Add Contao recipe
* Fix command argument
* Enable maintenance mode in both the current and release build
* Add the contao:manager:lock task
* Use correct public path in shared_dirs
* Make sure that the directory exists
* Update writable.php
Only add the the remote user to setfacl command if he exists as an os user.
* Replace is_int() with !empty().
run() usually returns a string, so the static analyzer throws an error, when using is_int() on its return value.
* Use test() instead of run()
Use test() instead of run to check whether the remote user also exists as an os user.
* Refactor deploy:cleanup Command
Remove $runOpts since it's not actually used
Move release symlink deletion to beginning of method. This will
allow the release symlink to be deleted even if deleting the old
releases fails.
* Refactor deploy:releases_log
Fixes issue where multiple failed releases in a row cause old
releases to not be cleaned up.
Fixes#2759
Co-authored-by: Anton Medvedev <anton@medv.io>
* Remove temporary workaround in Shopware recipe
The workaround is no longer needed, since it was fixed in Shopware 6.4.6.0 (NEXT-17720)
* Reverted removal of temporary workaround
Kept workaround for Shopware installations <6.4.6.0 and added comment for information on fixed version
* Fail silently for shopware < 6.4.6 on different absolute paths in theme config
* Updated docs for shopware recipe
Co-authored-by: Philipp Zabel <pza@hair-shop.com>
