.gardenignore
files), which makes it more flexible than hot reloading.build
/dist
directory into your container while running local, incremental builds (without having to remove those directories from your ignorefiles).exclude
field on each configured sync! Otherwise you may end up syncing large directories and even run into application errors.devMode
to your module/service configuration to specify your sync targets:container
moduleskubernetes
and helm
modulesdeploy
or dev
commands:one-way
or two-way
sync modes, and then graduate to a more fine-grained setup based on one-way-replica
and/or one-way-replica-reverse
once you're ready to specify exactly which paths to sync and which files/directories to ignore from the sync.one-way-safe
(or alias one-way
)source
path to a remote target
path.target
path.target
that you don't want to override with the contents of the local source
.source
/target
pair in question, you may want to use one-way-replica
instead.one-way-replica
source
path to a remote target
path, such that target
is always an exact mirror of source
(with the exception of excluded paths).source
always override the contents of target
.one-way
/one-way-safe
. However, you may need to configure more fine-grained/specific source
/target
pairs and their excludes such that you don't have problems with paths in the remote target
being overwritten/deleted when they change in the local source
.one-way-reverse
one-way
, except the direction of the sync is reversed.target
path to a local source
path.one-way
: Simple to configure, but conflicts are possible.one-way-replica-reverse
one-way-replica
, except the direction of the sync is reversed.target
path to a local source
path, such that source
is always an exact mirror of target
(with the exception of excluded paths).target
always override the contents of source
.two-way-safe
(or alias two-way
)source
to a remote target
path.source
will be synced to the remote target
.target
will be synced to the local source
.one-way
, this mode is simple to configure when there are files in either source
or target
that you don't want overridden on the other side when files change or are added/deleted.one-way-replica
and one-way-replica-reverse
syncs instead of one-way
and two-way
is generally the best approach long-term, but may require more fine-grained configuration (more sync specs for specific subpaths and more specific exclusion rules, to make sure things don't get overwritten/deleted in unwanted ways).two-way-resolved
two-way-safe
except:source
will always win any conflict. This includes cases where alpha’s deletions would overwrite beta’s modifications or creationsone-way
, one-way-replica
and two-way
sync modes, alpha is source
and beta is target
.one-way-reverse
and one-way-replica-reverse
), alpha is target
and beta is source
..gardenignore
files) to dev mode syncs.dist
or build
directories (not version control them, not include them in builds or module versions), but still be able to sync them from your local machine to the running container (or from the running container to your local machine). This is easy to achieve with dev mode.local-kubernetes
and kubernetes
providers:kubernetes
provider) for a full list of provider-level options for dev mode when using the kubernetes
provider. The same dev-mode options are also available when using local-kubernetes
.mutagen
CLI directly.mutagen
CLI without additional context. However, to make this easier, a symlink to the temporary directory is automatically created under <project root>/.garden/mutagen/<random ID>
, as well as a mutagen.sh
helper script within that directory that sets the appropriate context and links to the automatically installed Mutagen CLI. We also create a <project root>/.garden/mutagen/latest
symlink for convenience.