Last updated
Was this helpful?
Last updated
Was this helpful?
Here, we'll describe at a high level the common day-to-day usage of the Garden CLI, with specific examples.
The 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 .
If you've not installed the CLI yet, please check out the .
Most of the examples below assume that you've already defined a Garden project.
It is currently not advisable to run multiple dev
, build
, deploy
or test
commands in parallel 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.
Every Garden command supports a common set of option flags. The full reference can be found , but here are the most important ones:
--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 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.
--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 for most commands.
All option flags can be specified with a space or a =
between the flag and the value.
Deploy
actionsDeploy
s in a projectThis deploys all Deploy
actions to the default environment and namespace.
Deploy
s in a project to a non-default environment and namespaceThis deploys all Deploy
actions to my-namespace
in the dev
environment.
Deploy
Deploy
When arguments accept one or more actions we space-separate the names.
Deploy
with sync enabledDeploy
containerDeploy
containerNote: This assumes that sh
is available in the container.
Deploy
sDeploy
s in JSON formatThis is suitable for parsing with e.g. the jq
utility.
Deploys
sThis removes all running Deploy
actions in my-namespace
in the dev
environment.
Deploy
Test
actionsThis is handy for running a single test and streaming the log outputs (garden test
, in comparison, is more meant to run multiple ones or watch for changes, and is less suitable for getting log output).
Run
actionsRun
actionBuild
actionsBuild
sBuild
s, forcing a rebuildBuild
Runs my-workflow
in my-namespace
in the dev
environment.
Deploy
sDeploy
Deploy
actionThe garden dev
command runs the Garden interactive development console. In that console you can execute Garden commands in interactive mode, like build
, deploy
, run
, test
and others. To see the full list of available commands execute the help
command in the development console.
This you can use to parse in scripts, e.g. using jq
.
You can also output in YAML with --output=yaml
.
This bootstraps a boilerplate garden.yml
with a project definition in the current directory, and a .gardenignore
file.
Individual plugins (currently referred to as 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.
You can run garden plugins
without arguments to list the available commands.
Here we initialize the cluster configured for the dev
environment:
Garden plugins generally define their external tool dependencies, such that Garden can automatically fetch them ahead of use. The 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.
Note that this command currently only works when run within a Garden project root.
If you use this frequently, we recommend defining the following helper function for quick access:
You can then type e.g. gt docker build .
to run docker build .
using the Garden-provided version of the docker CLI
.
Run garden tools
to get a full list of available tools, and garden tools --help
for more usage information.
Note that the --
is necessary to distinguish between Garden options, and kubectl arguments. See above for a shorthand function you can put in your shell profile.
This prints the absolute path to the kubectl
binary defined by the kubernetes
provider, downloading it first if necessary.
See the for more information on how to configure and use syncing for rapid iteration on Deploy
s.
For rapid iteration on a running Deploy
action, you can use a feature called sync mode. See the for details on how to configure and use that feature.
are a handy way to extract generated values from your project.
See the to learn more about actions and how to create them.
Remote sources are a mechanism to connect multiple git repositories in a single Garden project. See the for more information, including how to use the CLI to manage these sources.
When using a remote Kubernetes cluster and in-cluster building, the cluster needs to be set up with some shared services when you first start using it, when you update the provider configuration, or sometimes when you update to a new Garden version. See the for more information.
The terraform
provider includes several commands that facilitate interaction with the Terraform stacks in your project. See the for more information.
Take a look at our for in-depth guides on specific use cases and setups, or keep exploring other sections under to learn more about Garden concepts and configuration.