* #2423 shopware: task sw:plugin:activate:all runs migration script in wrong order
- add dependency for polyfill (to use str_ends_with)
- marcj/topsort (for sorting the shopware modules)
* #2423 shopware: task sw:plugin:activate:all runs migration script in wrong order
- get the plugin list
- read the composer names and dependencies from composer.lock
- order by dependencies
- use sorted list for activation and migration
* #2423 shopware: task sw:plugin:activate:all runs migration script in wrong order
Update changelog
* #2423 shopware: task sw:plugin:activate:all runs migration script in wrong order
do not update doc, but remove require autoload.php
* Safety to avoid modifying files outside deploy_path
Using writable_dirs with writable_use_sudo can lead to a disaster on a server (example using /var/log instead of var/log as writable dir).
* Update writable.php
* Update CHANGELOG.md
* Update CHANGELOG.md
* Update writable.php
* trailing slash
* docgen
* throw exception if absolute path in writable dirs
Composer installer can now take an argument to select which version channel to use: https://github.com/composer/getcomposer.org/pull/156/files
This allows for exemple to stay on major version 1 without specifying a specific Composer version
* Magento2: look for database migrations in order to get zero downtime deployments when changes are not needed
- also keep maintenance status active in case it was already previously activated
* Magento2: adjust shared dirs
* Magento2: dump autoload before setup di compile
- fix for magento 2.4 deployments https://github.com/magento/magento2/issues/23251
* Magento2: force static content deploy
- avoids deployment failure when magento production mode is not set
* Magento2: update change log
* Magento2: update recipe docs
* Revert "Magento2: force static content deploy"
This reverts commit 45de3337a5a3e524685c422be3fbc6957fe6b480.
* Magento2: detect configuration changes, launch config import
* Magento2: refactor recipe
- make all tasks compatible with any magento 2 version (skip command execution if still does not exist in certain version)
- remove duplicated check on maintenance status
- remove catch for processFailedException
Co-authored-by: Unai Lopez <unai.lopez@vdshop.es>
Co-authored-by: Peter Jaap Blaakmeer <peterjaap@blaakmeer.com>
Created new container using Ubuntu 20.04 as a base, for a E2E test
environment for the provision recipe.
Due to container sharing a kernel with host os, the firewall provisioning
had to be turn off during the testing procedure.
* fixed issue #2209
Copy shared files and folder should be verbose only when deployer is run with Very verbose output
* updated CHANGELOG.md
* changed to -vvv
* changes sprintf to interpolation
Reworked the `deploy:check_remote` step, to use the `on(localhost(), ...)`,
instead of relying on `runLocally`.
This has been changed, to make sure that the all functions that
are being executed and are related to "local" part of the logic,
are ran on the local host.
Previously in `runLocally(sprintf("%s ls-remote $opt $repository $ref", get('bin/git')));`
the `get('bin/git')` would've been executed on the remote host, which
could have resulted in an unexpected behaviour.
By closing all of the instructions, in the closure that is executed
by the `on()` function, we are sure that the context is set to the
right host.
Do not update upgradeable plugins, it updates code too. What we actually want is to run the migration. But the database:migrate --all command only runs the migrations for the core. Added a task that runs migrations for all plugins too.
Added || true to not let it fail on non-existing database migrations. This can be removed when this commit is released; 2a8a76fd83
* Update shopware6.php
I'm not sure wether this is interesting for your @peterjaap I hacked a script with the horrible table output to install, upgrade and activate all plugins
* Update shopware6.php
made it a static function
