You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On macOS (darwin) for environments that utilize Mutagen sync sessions (currently only magento2 environments leverage them, although I expect this to extend to other types fairly soon) sync should automatically start and stop when the user runs env start, env stop, up and down. This should also resolve issues caused where env up -d is run re-creating php-fpm containers breaking the sync session, as the operation would then be followed by re-creating the sync session rather than counting on the user to do so manually. Implementation of this should be such that running a start or up command does not re-create the sync session if one already exists (unless it’s broken, indicating container was re-created)
The text was updated successfully, but these errors were encountered:
Template init.sh script has also been updated, so as long as the latest init.sh script is on a project when 0.3.0 is released, the script will only call sync start directly on versions of Warden older than 0.3.0: wardenenv/warden-env-magento2@b3f6ad6
…n env types not using Mutagen sessions
Due to changes made to implement #90 failing to account for env types not using sync sessions, these commands would exit with the following error and a non-zero exit code:
Mutagen configuration does not exist for environment type "magento1"
On macOS (darwin) for environments that utilize Mutagen sync sessions (currently only
magento2
environments leverage them, although I expect this to extend to other types fairly soon) sync should automatically start and stop when the user runsenv start
,env stop
,up
anddown
. This should also resolve issues caused whereenv up -d
is run re-creatingphp-fpm
containers breaking the sync session, as the operation would then be followed by re-creating the sync session rather than counting on the user to do so manually. Implementation of this should be such that running a start or up command does not re-create the sync session if one already exists (unless it’s broken, indicating container was re-created)The text was updated successfully, but these errors were encountered: