I've used mutagen in the past before garden and never had this issue with similar length directories

Is it the length of the full ./.garden/mutagen directory that causes the issue? If so you could set up a short

~/.gdn/mut

directory or something automatically to host that out of that is at least independent from the folder the project is in.

I believe it's the length of

$HOME/$path/$to/$project

but I could be wrong.

Hi, im thinking about using garden for our CI. The problem I face is I use kubernetes and have 5 or so downstream services that are part of the integration test. Before merging to prod i would like to know that the project being worked on works well with all those other 4, and likewise those other 4 work well with this project. When the integration test works there might be service 1 calling 2 and 2 calling 3 and so forth. What i'm wondering with Garden is when a test runs how does it know to route the traffic well for a new version of 2 being tested (how does 1 know to call this other version of 2)? Currently we use DNS names (the name of the kubernetes service) for 1 to call 2. Im just a bit confused as to how this bit works

I think the error that we get when updating kubernetes-client/javascript to 0.18.1 (https://github.com/kubernetes-client/javascript/issues/1013) might be another problem that is being caused by Vercel PKGs nasty monkey patching in the boostrap.js (https://github.com/vercel/pkg/blob/main/prelude/bootstrap.js#L1988).

@swift-garage-61180 you have these two assigned to you, have you done any work on either and do you see yourself completing them? If not team core can bring them to the finish line no problem so feel free to pass 'em to us

Ah yes, go ahead please!

You can unassign me from those—I'm knee deep in other work at the moment.

@Anna and me discovered a pretty critical regression in 0.13.7 (was working in 0.13.6): kubernetes actions (and modules) caching does not work properly. If the manifest changes, garden still considers the deploy unchanged and does not correctly deploy the latest version: https://github.com/garden-io/garden/issues/4811 This came to our attention because the garden-platform pipeline stopped updating our internal garden cloud instances

There's something off with the way the flower emoji/icons in the nav section headings are being rendered on GitBook. The "undefined" in front of "misc" should be a flower/plant/organism of some kind, and there are two emoji/icons in the "advanced" heading (see the code screenshot for comparison).

cc @bright-policeman-43626 I think this might be related to the Garden Seeds PR

we are back under 200 open issues on the garden core repo https://github.com/garden-io/garden/issues current count: 195

I'm running a test using

kubernetes-exec

and for some reason it always takes about a minute longer than it actually should to finish with a success. Any idea why that would be and if I'm doing something wrong?

ℹ test.otlp-http-integ [debug] → Execing command in otel-collector-test-testing-tim/Pod/otlp-http-6968fb7db9-rq9qm/otlp-http: npm run integ
ℹ test.otlp-http-integ [verbose] → [npm run integ] 
> otlp-server@1.0.0 integ
> mocha test/integ.js
ℹ test.otlp-http-integ [verbose] → 
> otlp-server@1.0.0 integ
> mocha test/integ.js
[silly] Calling Cloud API with POST events
[silly] Retrieving client auth token from config store
ℹ test.otlp-http-integ [verbose]
ℹ test.otlp-http-integ [verbose]
ℹ test.otlp-http-integ [verbose]
ℹ test.otlp-http-integ [verbose]
ℹ test.otlp-http-integ [verbose] → [npm run integ] OTLP HTTP service started
ℹ test.otlp-http-integ [verbose] → OTLP HTTP service started
ℹ test.otlp-http-integ [verbose] → [npm run integ]   Traces endpoint
ℹ test.otlp-http-integ [verbose] →   Traces endpoint
ℹ otel-collector-process [silly] → 2023-07-14T11:51:42.958+0200 debug   otlphttpexporter@v0.80.0/otlp.go:116    Preparing to make HTTP request  {"kind": "exporter", "data_type": "traces", "name": "otlphttp/1", "url": "http://otel-collector-test.local.demo.garden:80/v1/traces"}
ℹ test.otlp-http-integ [verbose] → [npm run integ]     ✔ should receive traces from the exporter (276ms)
ℹ test.otlp-http-integ [verbose] →     ✔ should receive traces from the exporter (276ms)
ℹ test.otlp-http-integ [verbose]
ℹ test.otlp-http-integ [verbose]
ℹ test.otlp-http-integ [verbose]
ℹ test.otlp-http-integ [verbose]
ℹ test.otlp-http-integ [verbose] → [npm run integ]   1 passing (282ms)
ℹ test.otlp-http-integ [verbose] →   1 passing (282ms)
[silly] Calling Cloud API with POST events
[silly] Retrieving client auth token from config store
✔ test.otlp-http-integ → Success (took 61.9 sec)

Could anybody try running

get modules

with latest 0.12 in pulumi example on the

template-fixes

branch please? I get a weird error saying I have a duplicate module although I 100% have only one

Module k8s-namespace is declared multiple times (in 'k8s-namespace/garden.yaml' and 'k8s-namespace/garden.yaml')

I'm wondering if it's actually reproducible for someone else or is it just me

Found 559 errors

after setting

noImplicitOverride: true

/:

nice! i bet that could actually fix some subtle bugs

Does anyone know why we decided to go with zod for the new validators? We were using joi before - and still pretty extensively in the whole codebase - but I guess there must have been some drawbacks to that? Is it mostly just about typing and zod providing properly typed objects and schemas? I'm wondering if it wouldn't make sense to switch everything over to something natively compatible with JSON Schema like https://github.com/sinclairzx81/typebox. That way it should be a lot simpler to generate an overall config schema for editor autocompletion and also to have a single standardized way of generating reference docs.

I'm confused about the new action sync spec compared with the old module sync spec: In modules (https://docs.garden.io/reference/module-types/kubernetes#sync.paths-.defaultfilemode) we had -

sync.paths[].defaultFileMode

-

sync.paths[].defaultDirectoryMode

-

sync.paths[].defaultOwner

-

sync.paths[].defaultGroup

In actions (https://docs.garden.io/reference/action-types/deploy/kubernetes#spec.sync.defaults.filemode) we have now -

spec.sync.defaults.fileMode

-

spec.sync.defaults.directoryMode

-

spec.sync.defaults.owner

-

spec.sync.defaults.group

-

spec.sync.paths[].fileMode

-

spec.sync.paths[].directoryMode

-

spec.sync.paths[].owner

-

spec.sync.paths[].group

-

spec.sync.paths[].defaultFileMode

-

spec.sync.paths[].defaultDirectoryMode

-

spec.sync.paths[].defaultOwner

-

spec.sync.paths[].defaultGroup

If I understand correctly, they all do the same thing. Why do we have so many options that do the same thing? Am I right and this is a mistake/ oversight or is there a reason for this? Can we remove (or hide) some of those to make the docs more clear?

Been wanting to do this forever: https://github.com/garden-io/garden/pull/4889

cc @polite-fountain-28010

I've been hunting issue due to inconsistent doc here: https://docs.garden.io/kubernetes-plugins/remote-k8s/configure-registry/gcp . all code snippets here contain ${PROJECT_ID} for code that i need to replace except for the last code snippet which uses

docker.pkg.dev

. Description above instruct to replace, but I was blindly copy-pasting this and had to go pretty deep to figure htis out. using

${REGISTRY_HOSTNAME}

would probably make it more obvious that this needs replacing. Same can be said for

gcr.io

above probably.

Also - another issue i am unable to work-around is related to

Options:[rbind ro]}]: operation not permitted errors

. It is described here and i'm using

gardendev/buildkit:v0.10.5-2-rootless

, the emptyDir is mounted on /garden-build , however buildkit is still erroring. I'm using cos_containerd on GKE (1.24.13-gke.2550), happy to debug this further. I'm attempting to use

rootless:true

build with kaniko or cluster-buildkit

Since we might be doing a hackathon soon, I thought I'd point out how simple and intuitive it's become to write new plugins with the new plugin system (which is an early iteration of what will become a public-facing plugin SDK). Check out these two files from the Docker Compose plugin that was submitted for review yesterday: https://github.com/garden-io/garden/blob/docker-compose/plugins/docker-compose/schemas.ts Thanks to Zod, we no longer have to separately write interfaces to go with the schemas (which was an endless source of paper cuts with Joi). https://github.com/garden-io/garden/blob/docker-compose/plugins/docker-compose/index.ts Defining action types and adding the handlers is also really simple now. The whole thing is starting to feel a lot more like writing a library for Garden than contributing to the internals of Garden (which is what it's felt like to write plugins in the past). We're getting to a place where writing amazing plugins is quite frictionless! Mapping the domain and writing the logic is always work, but there's very little ceremony involved now.

Hey All, I'm having good progress with Garden and currently trying to integrate it into my pipeline. I'm following https://docs.garden.io/guides/using-garden-in-ci but I have some questions: 1. i want garden to tag images with the tag of my choice when they are being built - e.g. #1.0.234 is there a way to specify a tag? 2. alternatively - it can use whatever tag for my multiple images, but I'd like to know that so I can incorporate that inside my helm/values.yaml as I'm prepping it up for a new release. Any ideas?

Has anyone managed to successfully complete the quickstart-example using docker-desktop on ubuntu? The code on github appears to be broken as it appears to fail with Python Flask errors

ImportError: No module named abc

which then triggers

BackOff - Back-off restarting failed container app

Since we've been talking about more internal docs: I wrote a doc that summarizes the way graph execution (solver + task classes) works in Garden. Hope it's useful! https://github.com/garden-io/garden/pull/4970

Having dug into the code some more and looks like we want to read the manifests from the

.build

dir. But it's just not clear to me what that should be in the context of a Deploy action. https://github.com/garden-io/garden/blob/main/core/src/plugins/kubernetes/kubernetes-type/common.ts#L118

Could I get an approval from someone on this? 🙏 https://github.com/garden-io/garden/pull/4978 Vova had reviewed it last week, and I think it should be good to go. It's only documentation, so it's not going to cause any regressions at any rate.

Welcome!

acoustic-dusk-48036

joined #💻｜dev. Also,

gifted-thailand-88875

joined.