The end-to-end tests for

e2e-remote-sources-modules

started failing recently—any ideas what might be causing this, @alert-helicopter-61082?

@swift-garage-61180 tracked in thread above https://discord.com/channels/817392104711651328/1110225946759405662

When running two processes of core, in the second process (deploying garden-platform itself), I get

Unexpected error handling request ID f22385ff-c69f-4671-8056-a1f74e773dab: Unable to process request: Lock file is already being held

. Other than that, logs are streamed and I don't see an actual error. Not sure what other context I can provide, but it's easy to reproduce on my end

We also need to figure out why those microk8s tests keep failing as of recently. I think it started happening last week.

can I somehow tell bonsai when a kubernetes deploy action should considered to be ready? we use jobs in certain scenarios and those are considered deployed even before they run and also if they fail

or that should be a kubernetes-pod run?

is this new in bonsai?

ℹ deploy.ingress-nginx → Waiting for resources to be ready...
ℹ deploy.ingress-nginx → DaemonSet/ingress-nginx-controller: Pulling image "registry.k8s.io/ingress-nginx/controller:v1.7.0@sha256:7612338342a1e7b8090bef78f2a04fffcadd548ccaabe8a47bf7758ff549a5f7"
ℹ deploy.ingress-nginx → DaemonSet/ingress-nginx-controller: RELOAD NGINX reload triggered due to a change in configuration

(I don't remember relevant events propagated to the output in 0.12) love it!

Is there a way I can explicitly define how to wait for certain resources within a kubernetes deploy action?

@icy-furniture-17516 it seems you have played around with Bonsai a bit, have you noticed any bugs, undocumented things or just problems you ran into while trying it out?

What is our policy for

edge

versions moving forward? branch

main

->

edge

? And

0.12

->

0.12-edge

or something?

I spent like an hour trying to get microk8s to work to debug the failing integ tests but it's just not functioning for me with an multipass issue I don't feel like debugging. Would anybody else care to install microk8s and see if the test failures are locally reproducible?

Yes, me!

Can you offer instructions for reproducing?

bonsai docs are 404 for me atm (I suppose it's just because of the release, but I guess it's better to notice in case it's really an error)

they should be arriving to the latest docs / main in just a few moments as soon as the gitbook deploys 🤞

The

garden dev

command appears to OOM for me after running for some time. Second time I notice it, but in both cases it ran for quite awhile (probably hours), see attached stack trace https://cdn.discordapp.com/attachments/1088795679159222292/1110579502863614105/message.txt

Little FYI - the release notes at https://github.com/garden-io/garden/releases/tag/0.13.0 have a line ("See the before & after section below for a more detailed example of this.") which links to a non-public notion doc.

Good catch, thanks! Looks like we made a copy-paste mistake when we copied the release notes over and didn't include the before & after section. I've just added that in now.

@brief-restaurant-63679 Why isn't the

renderError

[1] used for the terminal log writer in `formatForTerminal combineRenders`[2]? This causes this error log[3] in the dev command-line to be empty. Should I just pass the

error.message

as

msg

? 1. https://github.com/garden-io/garden/blob/main/core/src/logger/renderers.ts#L47 2. https://github.com/garden-io/garden/blob/main/core/src/logger/renderers.ts#L168 3. https://github.com/garden-io/garden/blob/main/core/src/cli/command-line.ts#L102

I removed this because

renderError

resulted in way too much detail being rendered in the terminal writer. Rendering the message without the detail is probably the right compromise.

looks like we're not running CI on the

0.12

branch so we're not getting

edge-acorn

releases 🤔 https://app.circleci.com/pipelines/github/garden-io/garden?branch=0.12

@ancient-diamond-80011 I got ahead of myself and started implementing the exec outputs

Should

quickstart-example

bugs be submitted to the

quickstart-example

GitHub issues tracker or in

garden

?

anyone familiar with our

log

implementation (especially regarding the sub-logs / tree structure details) available for a quick pairing session to verify some details?

For Empathy Sessions previous to Bonsai's release I've been having users test with

sh
TEMP_DIR=$(mktemp -d)
curl -sSL https://github.com/garden-io/garden/releases/download/edge-bonsai/garden-edge-bonsai-macos-amd64.tar.gz | tar xz -C $TEMP_DIR
mkdir -p $HOME/.garden/bin
rm -rf $HOME/.garden/bin/*
mv $TEMP_DIR/macos-amd64/* $HOME/.garden/bin
grep -qxF 'export PATH=$HOME/.garden/bin:$PATH' "$HOME/.zshrc" || echo 'export PATH=$HOME/.garden/bin:$PATH' >> "$HOME/.zshrc"
rm -r $TEMP_DIR
source $HOME/.zshrc

do we want to change this command now that Bonsai is released? What do we want them finding bugs and papercuts in?

Mikael and I just noticed that we are still using our forked javascript client https://github.com/garden-io/garden/blob/main/core/package.json#LL29C32-L29C88 in bonsai, while we moved away from it in

0.12

https://github.com/garden-io/garden/blob/0.12/core/package.json#LL29C32-L29C41 Why is that so?

@big-spring-14945 just opened this issue https://github.com/garden-io/garden/issues/4461

About this one: https://discord.com/channels/817392104711651328/1111730980726775960/1111730980726775960 A natural way to fix this in Core would be to extend the logic I wrote here to detect all immutable spec fields. https://github.com/garden-io/garden/pull/3884

Good news: Podman Desktop running kind rootless powered by Podman container engine just works no special magic needed. Used quickstart-example to test. I'll try and make a docs PR next week.

Couldn't resist kicking the tires as a hobby project over the weekend :-)