kubernetesprovider is used,
containermodules can be configured to hot-reload their running services when the module's sources change (i.e. without redeploying). In essence, hot-reloading syncs files into the appropriate running containers (local or remote) when code is changed by the user, and optionally runs a post-sync command inside the container.
For example, services that can be run with a file system watcher that automatically updates the running application process when sources change (e.g. nodemon, Django, Ruby on Rails, and many other web app frameworks) are a natural fit for this feature.
Currently, services are only deployed with hot reloading enabled when their names are passed to the
garden devcommands (e.g.
garden dev --hot=foo-service,bar-service). If these services don't belong to a module defining a
hotReloadconfiguration (see below for an example), an error will be thrown if their names are passed to the
You can also pass
--hot-reload=*) to deploy all compatible services with hot reloading enabled (i.e. all services belonging to a module that defines a
Subsequently deploying a service belonging to a module configured for hot reloading via
garden deploy(without the watch flag) results in the service being redeployed in standard configuration.
Since hot reloading is triggered via Garden's file system watcher, hot reloading only occurs while a watch-mode Garden command is running.
Following is an example of a module configured for hot reloading:
description: My Test Service
- target: /app
- name: test-service
args: [npm, start] # runs `node main.js`
hotReloadArgs: [npm, run, dev] # runs `nodemon main.js`
In the above, the
hotReloadfield specifies the destination path inside the running container that the module's (top-level) directory (where its
garden.ymlresides) is synced to.
Note that only files tracked in version control are synced, e.g. respecting
sourceis specified along with
target, that subpath in the module's directory is synced to the target instead of the default of syncing the module's top-level directory.
You can configure several such
targetpairs, but note that the
sourcepaths must be disjoint, i.e. a
sourcepath may not be a subdirectory of another
sourcepath within the same module. Here's an example:
- source: foo
- source: bar
hotReloadArgsspecifies the arguments to use to run the container (when deployed with hot reloading enabled). If no
argsis also used to run the container when the service is deployed with hot reloading enabled
postSyncCommandcan also be added to a module's hot reload configuration. This command is executed inside the running container during each hot reload, after syncing is completed (as the name suggests).
Following is a snippet from the
hot-reload-post-sync-commandexample project. Here, a
postSyncCommandis used to
toucha file, updating its modification time. This way,
nodemononly has to watch one file to keep the running application up to date. See the
hot-reload-post-sync-commandexample for more details and a fuller discussion.
description: Node greeting service
- target: /app
postSyncCommand: [touch, /app/hotreloadfile]
- name: node-service
args: [npm, start]
hotReloadArgs: [npm, run, dev] # Runs modemon main.js --watch hotreloadfile