FAQ
Last updated
Was this helpful?
Last updated
Was this helpful?
You will have to use the top-level directive to specify which files belong to each Build. You will also have to provide the path to the Dockerfile with the directive.
.gitignore
the .garden
dir?Yes.
You can explicitly set in which environments the action should be used like so:
You can also use the disabled
field to disable actions.
include
/exclude
fields? How are they different from the project-level scan.include
/scan.exclude
fields? What about ignore files?Read all about it in of our docs.
We recommend using the Terraform or Pulumi actions for cloud services that are shared by your team.
You can also deploy kubernetes
and helm
actions to their own namespaces.
Alternatively you can hoist your garden.yml
file so that it is at the same level or parent to all relevant build context and use the include
field.
v-<something>
versions mean, and why are they different between building and deploying?You may notice that a version of a Build action is different from the version the Deploy for that Build. This is because the Deploy's version also factors in the runtime configuration for that deploy, which often differs between environments, but we don't want those changes to require a rebuild.
Yes, but only since Garden 0.13.
Set the log-level to verbose
or higher. For example:
Yes. Generally Dockerfiles need to be in the same directory or a child directory relative to your Garden action but you can always set the source path for the action with the source.path
field.
For example, let's say you have the following project structure:
In this case the recommended approach is to set the source.path
field like so:
Alternatively you can hoist the garden.yml
for the api
to the root of the project and e.g. call it api.garden.yml
. In that case your config will look like this:
garden-system
namespace?Please do not delete the garden-system
namespace directly, because Kubernetes may fail to remove persistent volumes. Instead, use this command:
It removes all cluster-wide Garden services.
We've been pondering this, but there are a lot of variants to consider. The key issue is really that the notion of "first time" is kind of undefined as things stand.
So what we generally do is to make sure Runs are idempotent and exit early if they shouldn't run again. But that means the process still needs to be started, which is of course slower than not doing it at all.
It is, which is why we recommend that Runs are written to be idempotent. Runs by nature don’t really have a status check, unlike Deploys.
garden deploy
?The Run result is likely cached. Garden won't run Runs with cached results unless spec.cacheResult: false
is set on the Run definition.
You can also run it manually with:
This will run the Run even if the result is cached.
buildArgs
for docker Builds?No, Kubernetes secrets can only be used at runtime, by referencing them in the spec.env
field of Run, Deploy and Test Actions.
Also note that secrets as buildArgs
are considered a bad practice and a security risk.
Garden interfaces with your cluster via kubectl
and by using the Kubernetes APIs directly and should therefore work with all Kubernetes clusters that implement these. Garden is committed to supporting the latest six stable versions of Kubernetes.
We're in the process of applying for becoming a Verified Docker Publisher which should significantly reduce the chance of being rate limited.
In the meantime, you have the following options:
Option 1 — Crate a Docker Hub image pull secret:
Then add the name and namespace of the secret you created to the imagePullSecrets
field of the Kubernetes provider:
This also works for the local-kubernetes
provider.
Option 2 — Use a registry mirror:
If you already have your own Docker Hub registry mirror set up you can use that by setting the utilImageRegistryDomain
field on the Kubernetes provider:
This also works for the local-kubernetes
provider.
You can install the edge release of Garden 0.14 (Cedar) by using the Garden self-update
command like so:
We're exploring how we can release it incrementally. Please let us know if this is something you're interested in.
*.local.demo.garden
domain?The *.local.demo.garden
domain resolves to 127.0.0.1 via our DNS provider for convenience. If you want to use a different hostname for local development, you’ll have to add the corresponding entry to your hosts file.
Garden is currently in use by many teams. We don’t have a set date or plan to label it as 1.0, but we don't expect to do it anytime soon.
Garden is not currently designed to work in air-gapped environments but if you have done the initial setup and use a local kubernetes provider it might work.
You can disable terminal colors with the NO_COLOR
environment variable. For example:
You can use the for that. See .
See this for more discussion on the two approaches.
These are the Garden versions that are computed for each action in the Stack Graph at runtime, based on source files and configuration for each action. See for more information about how these work and how they're used.
Use the .
See .
If you need the Dockerfile outside of the Build root because you want to share it with other Build actions, you could also consider having a single base image instead and then let each action have its own Dockerfile that's built on the base image. See the for an example of this.
See .
Use the .
You can use the field. For example:
See also the for an example of this.
You'll need to use the or action types for that. Here's the official for mounting secrets as files.
No, secrets have to be in the same namespace as the project. This is how Kubernetes secrets are designed, see .
You can generate the files via a Run, store them as artifacts, and copy them from the local artifacts directory. of this.
You can set annotations on ingresses under the .
Garden uses a handful of utility images that are hosted on under the gardendev
repository and under heavy usage, users can get rate limited when deploying them.
First follow the steps in to create an image pull secret for Docker Hub.
By setting persistent: true
on exec
Deploy actions. for more.
You can learn more about .
Yes! two-way
sync mode can be configured with Garden sync mode. See
We have a team of people working on it full-time, and we make it a priority to address all non-trivial bugs. We’re also happy to help out and answer questions via .