garden
CLI is how you work with Garden in most scenarios, during development and in CI pipelines. It features a fairly large number of commands, so we'll list the most common ones below. You can run garden --help
to list them, and use garden <command> --help
to learn more about individual commands, arguments, option flags, usage examples etc. You can also find a full reference here.--watch
flag) all start a web dashboard that you can open in a browser. See the dashboard section for more on that.--watch
because they may interfere with each other. It is fine, however, to run one of those and then run other commands to the side, such as garden logs
. We plan on improving this in the future.--env
sets the environment (and optionally namespace) that the command should act on. Most Garden commands only act on a specific environment, so in most cases you'll specify this, unless you're working on the default environment for the project. See here for more about environments and namespaces.--log-level
/ -l
sets the log level. Use e.g. -l=debug
to get debug logs for the command.--logger-type=basic
disables the fancy log output (with spinners etc.) and just prints a simple line-by-line output. Setting GARDEN_LOGGER_TYPE=basic
does the same thing. You should set that environment variable in CI and other automated environments.--output
/ -o
sets the output format. Use this to get structured output from the commands. --output=json
outputs JSON, and --output=yaml
outputs YAML. The structure of the outputs is documented in the reference for most commands.=
between the flag and the value.my-namespace
in the dev
environment.--hot-reload
implicitly sets --watch=true
.sh
is available in the container.jq
utility.my-namespace
in the dev
environment.integ
test, defined in my-module
, and watches for changes (including changes in modules and services that the test depends on).garden test
, in comparison, is more meant to run multiple ones or watch for changes, and is less suitable for getting log output).my-workflow
in my-namespace
in the dev
environment.garden dev
command builds, deploys and tests all parts of your project, and also runs any tasks that are listed as dependencies for your services and tests. It then waits for any code changes, and automatically re-builds, re-deploys and re-runs any parts affected by your code changes.--watch
flag all start a web dashboard that you can open in a browser. See the dashboard section for more on that.jq
.--output=yaml
.garden.yml
with a project definition in the current directory, and a .gardenignore
file.garden.yml
with a module definition in the current directory. You'll get an interactive menu to select a module type. You may get suggestions for appropriate module types, depending on which files are found in the directory (such as a container
module when a Dockerfile
is found).providers
in your project configuration) may include specific commands that help with their usage and operation. The available commands will depend on which providers are configured in your project.garden plugins
without arguments to list the available commands.dev
environment:terraform
provider includes several commands that facilitate interaction with the Terraform stacks in your project. See the Terraform guide for more information.garden tools
command exposes these tools, so that you can use them without having to install them separately. You can also use these to ensure that you're using the exact same versions as the Garden plugins.gt docker build .
to run docker build .
using the Garden-provided version of the docker CLI
.garden tools
to get a full list of available tools, and garden tools --help
for more usage information.--
is necessary to distinguish between Garden options, and kubectl arguments. See above for a shorthand function you can put in your shell profile.kubectl
binary defined by the kubernetes
provider, downloading it first if necessary.