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
Due to the lack of ANY shopware6 installation routine, here's my little beginning of it. If you think it can be made better, I am very happy to have your ideas on board of this.
Fix wrong change introduced in 62db938884
`.env` file should not be shared because it's release-specific. On the other hand, `.env.local` and `.env.local.php` files are specific to deployment environment and should be shared between releases.
See for details: https://github.com/deployphp/deployer/pull/1907#issuecomment-533779139
The .env and .env.<environment> files should be committed to the shared repository because they are the same for all developers and machines. However, the env files ending in .local (.env.local and .env.<environment>.local) should not be committed because only you will use them. In fact, the .gitignore file that comes with Symfony prevents them from being committed.
https://symfony.com/doc/current/configuration.html#managing-multiple-env-files
* Add tasks to cache a manifest of event listeners
Laravel supports automatic discovery of events and listeners since
version 5.8.9. (https://laravel.com/docs/5.8/events#event-discovery)
As the documentation states, you want to cache the manifest of event
listeners in a production environment to prevent scanning the
directories on every request.
The new tasks are not added to the deploy task because automatic event
discovery is opt-in functionality in Laravel.
* Update CHANGELOG.md
* Add check_remote_head option to avoid unnecessary new releases by checking the remote git HEAD without cloning the repo.
* Add check_remote_head into the CHANGELOG
* Add the pull request link to CHANGELOG
* Update CHANGELOG.md
Removed extra spaces: https://github.com/deployphp/deployer/pull/1759
* Fix changelog. Improve check_remote_head
* Use GrasefulSutdown exception instead of exit(0).
* Change bash if statement in check_remote_head.
* Remove redundant code.
* Replace if statement with test.
* Update artisan cache commands
- Re-add `artisan:view:clear` command
- Modify the existing `artisan:view:cache` command to remove the call to clear the cache, as this is already completed by the Laravel Framework
* Updated changelog with laravel view cache changes
* Update CHANGELOG.md
Update newline spacing to fix scrutinizer failure
