The project configuration file should be located in the top-level directory of the project's Git repository. We suggest naming it
project.garden.ymlfor clarity, but you can also use
garden.ymlor any filename ending with
The other docs under the Using Garden go into more details, and we highly recommend reading through all of them.
Below, you'll also find some general information on how to configure a project.
By default, all directories under the project root are scanned for Garden actions. Depending on the action kind and type, files in the same directory as the action configuration file might be included as source files for that action. Often, you need more granular control over the context, not least if you have multiple actions in the same directory.
Garden provides three different ways to achieve this:
By default, all directories under the project root are scanned for Garden actions, except those matching your ignore files. You may want to limit the scope, for example if you only want certain actions as part of a project, or if all your actions are contained in a single directory (in which case it is more efficient to scan only that directory).
scan.excludefields are a simple way to explicitly specify which directories should be scanned for actions. They both accept a list of POSIX-style paths or globs. For example:
Here we only scan the
actionsdirectory, but exclude the
If you specify a list with
include, only those patterns are included. If you then specify one or more
excludepatterns, those are filtered out of the ones matched by
include. If you only specify
exclude, those patterns will be filtered out of all paths in the project directory.
scan.excludefield is also used to limit the number of files and directories Garden watches for changes while running. Use that if you have a large number of files/directories in your project that you do not need to watch, or if you are seeing excessive CPU/RAM usage. The
scan.includefield has no effect on which paths Garden watches for changes.
Generally, using .gardenignore files is far more performant than exclude config statements and will decrease graph resolution time.
By default, Garden respects
.gardenignorefiles and excludes any patterns matched in those files. You can place the ignore files anywhere in your repository, much like
.gitignorefiles, and they will follow the same semantics.
You can use those to exclude files and directories across the project, both from being scanned for Garden modules and when selecting source files for individual modules. For example, you might put this
.gardenignorefile in your project root directory:
This would cause Garden to ignore
publicdirectories across your project/repo, and all
Note that these take precedence over both
scan.includefields in your project config, and
includefields in your module configs. If a path is matched by one of the ignore files, the path will not be included in your project or modules.
dotIgnoreFiles: [.gardenignore, .gitignore]
This behaviour was changed in Garden
The default value of
If you're using Git submodules in your project, please note the following:
- 1.You may ignore submodules using .ignore files and include/exclude filters. If a submodule path itself (that is, the path to the submodule directory, not its contents), matches one that is ignored by your .ignore files or exclude filters, or if you specify include filters and the submodule path does not match one of them, the module will not be scanned.
- 2.Include/exclude filters (both at the project and module-level) are applied the same way, whether a directory is a submodule or a normal directory.
- 3..ignore files are considered in the context of each git root. This means that a .ignore file that's outside of a submodule will be completely ignored when scanning that submodule. This is by design, to be consistent with normal Git behavior.
We highly recommend reading all the other docs in this section to learn about the different configuration options and entities.