This section could (obviously) use more work. Contributions are most appreciated!
When running Garden commands against an Azure AKS cluster with RBAC enabled, an error like the following may appear:
Failed resolving provider Kubernetes. Here's the output:
Got error from Kubernetes API - Unauthorized
StatusCodeError from Kubernetes API - 401 -
This happens because Azure with RBAC enabled uses a different authentication mechanism that the Kubernetes client library doesn't support. The solution is to use Kubelogin. See also this GitHub issue.
This issue often comes up on Linux, and in other scenarios where the filesystem doesn't support event-based file watching.
Thankfully, you can in most cases avoid this problem using the
scan.excludefield in your project config, and/or the
excludefield in your individual action and module configs. See the Including/excluding files and directories section in our Configuration Files guide for details.
This is a known issue with Windows and may affect many Node.js applications (and possibly others). To fix it, you can open the Windows Defender Security Center and either
- a) disable Real-time protection; or
- b) click "Add or remove exclusions" and add "$HOME\.garden" to the list of exclusions.
You need to set tmux to use 256 colors. As per the official documentation, you can do that by adding
set -g default-terminal "screen-256color"or
set -g default-terminal "tmux-256color"to your
This could be because Garden is scanning the project files. Make sure you exclude things like
node_modulesor other large vendor directories. See this section of our docs.
Garden does create the ingress at the Kubernetes level. However, it does not print the ingresses with the CLI output and the Garden command call won't work. This is a known issue.
Pinging the service will still work, and you'll see the Ingress resource if you run
kubectl get ingress --namespace <my-namspace>.
This is a well-known Helm issue. You'll need to delete the release manually with
helm -n <namespace> uninstall <release-name>
This is likely because they're being excluded somewhere, e.g. in
Prior to Garden 0.13.0,
.gitignorefiles were respected by default. In Garden 0.13.0 that behaviour was changed. Now it's possible to only specify a single ".ignore" file in the project-level configuration.
Make sure to use the
outputsfield from the container module being referenced.
# Use the outputs field from the container module
This can occur if nginx is not able to bind to its default port which is port
80. Stopping the process that occupies the port should solve the issue.
You can also skip the nginx installation if you already have a separate ingress controller installed, by setting
setupIngressController: nullin your
If this error came up when running the
gardenbinary from inside your
~/Downloadsdirectory, try moving it outside the
~/Downloadsdirectory before running it again.
If you're still getting this error, a workaround is to find the
gardenbinary in Finder, CTRL-click it and choose Open. This should prevent this error message from coming up again.
See also: https://support.apple.com/en-gb/guide/mac-help/mh40616/mac
This is a bug in Docker CE (i.e. Docker for Desktop), version
2.4.x.y. See this GitHub issue comment for a fix and more details.
In some container repositories, you may need to create the cache repo manually.
This can occur if you re-install the Garden Nginx Ingress Controller. For example because you ran
garden plugins kubernetes uninstall-garden-servicesand then
garden plugins kubernetes cluster-initwhen upgrading the system services.
When the Ingress Controller gets re-installed, it may be assigned a new IP address by your cloud provider, meaning that hostnames pointing to the previous one will no longer work.
To fix this, run kubectl get svc -n garden-system and look for the EXTERNAL-IP of the garden-nginx-nginx-ingress-controller service and update your DNS records with this new value.