Exec (local scripts)
execplugin and corresponding
execactions allow you to run commands locally on the host (e.g. your laptop or your CI runner).
This plugin is built-in which means you don't need to specify it in your project configuration. You can simply add
execactions right away.
It's great for running auth scripts as well as executing various scaffolding scripts that need to run "locally".
It can also be used to start applications locally (e.g. by executing commands like
This can be very useful for hybrid environments where you have, say, your backend running in a remote production-like environment but your frontend running locally.
Usually you don't need to configure the
execplugin because it's built-in and you can use
However, it can be used to run init scripts ahead of other Garden execution. This is useful if you need to authenticate against a remote environment before Garden initializes other plugins.
Another set of popular use-cases are local build flows for shared libraries ahead of Docker builds, along with any sort of glue script you may need between steps.
Here's an example where we run a script to authenticate against a Kubernetes cluster before initializing the Kubernetes plugin:
# In your project level Garden config file
- name: exec
initScript: "sh -c ./scripts/auth.sh"
- name: kubernetes
dependencies: [ exec ] # <--- This ensures the init script runs before the K8s plugin is initialized.
The log output of the
initScriptcan be accessed via
Following are some example
execRun actions for executing various scripts:
include: [ ] # <--- No source files are needed
command: [ "sh", "-c", "./scripts/auth.sh" ]
include: [ ]
command: [ "sh", "-c", "./scripts/prepare-data-locally.sh" ]
Other actions can depend on these Runs:
dependencies: [ run.auth, run.prepare-data ]
command: [ yarn, run, db-init ]
It's also possible to reference the output from
- name: db
exec Deployaction type can also be used to start long-running processes:
deployCommand: [ "yarn", "run", "dev" ] # <--- This is the command Garden runs to start the process in persistent mode.
spec.persistent: trueif the
spec.deployCommandis not expected to return, and should run until the Garden command is manually terminated. The
spec.persistentflag replaces the previously supported