garden help
, which helps make your project easier to use and more self-documenting.garden api-dev
. Before the Garden command starts, we update the submodules in the repo, and then we start garden deploy
with some parameters that we tend to use or prefer.*.garden.yml
file in that directory, much like other configs, but we deliberately avoid scanning the entire project structure for commands. By extension, commands cannot be defined in remote sources at this time.exec
and gardenCommand
fields can be templated. Other fields need to be statically defined.name
, which must be a valid identifier (following the same rules as module names etc.). A short description must also be provided with description.short
, and you can also provide a longer description on description.long
which is shown when you run the command with --help
. For example:exec
and/or gardenCommand
. The former simply executes some command on your system, e.g. a shell command. The latter, as you might have guessed, runs a Garden command.exec
and gardenCommand
, the exec
part is run before the gardenCommand
.exec
field, you must specify exec.command
and can optionally set exec.env
as well, to set any environment variables for the command execution.gardenCommand
field is a simple array, which normally should start with the command name to run, and then any flags and arguments you want to pass on.exec
and gardenCommand
fields can be templated with many of the fields available for project and environment configuration. See the reference for all the fields available.${args.*}
and ${opts.*}
variables. You can see below how to explicitly define both positional arguments and option flags, but you can also use the following predefined variables:${args.$all}
is a list of every argument and flag passed to the command (only subtracting the name of the custom command itself). This includes all normal global Garden option flags, as well as the ones you explicitly specify.${args.$rest}
is a list of every positional argument and option that isn't explicitly defined in the custom command, including all global Garden flags.${args["--"]}
is a list of everything placed after --
in the command line. For example, if you run garden my-command -- foo --bar
, this variable will be an array containing "foo"
and "--bar"
.${opts.*}
, even those that are not explicitly defined. Unspecified options won't be validated, but are still parsed and made available for templating.join
helper function to convert all extra arguments to a space separated string, and pass that to the imagined foo.sh
script. Pretty much like using "[email protected]"
in a bash script. We also reference a couple of other common template variables (in this admittedly contrived example...).args
and opts
fields. These are validated and parsed before running the command, and are also shown in the help text when running the command with --help
. For example:"db"
if the option flag isn't set. To run this command, you could run e.g. garden run-task my-task --db test
, which would run my-task
with the dbHostname
variable set to test
.garden run-task my-task --db test --force
and the additional --force
parameter gets passed to the underlying Garden command.variables
field, and reference those in the exec
and gardenCommand
fields using ${var.*}
, similar to module variables. Note that project variables are not available, since the Garden project is not resolved ahead of resolving the custom command.