is there any known trick to avoid this kind of repetition to make the type system happy? https://github.com/garden-io/garden/pull/4497/files#diff-def0851e81190cb5605afe8d5779115f595aaa677399e2d72cdfb791fb766fe6R118-R128

Could someone from core kindly review super small fix in https://github.com/garden-io/garden/pull/4501 ? @purple-oyster-28927 and me are blocked by that issue doing some observability work

What is the Action-way to copy files from a dependency? Dependencies in action seems to be an array now, and there is no way to copy files anymore from other build actions?

anybody up to pair on a nvm ruining exec integ tests issue I'm having a bad time with rn

I accidentally merged a rather bad commit message so please forgive my sins

fixing terraform-plugin tests pr up for (hopefully final) review https://github.com/garden-io/garden/pull/4381 please note the comment thread in there with more details. cc @calm-family-29323 @astonishing-tomato-18259 @curved-intern-91221

Is there a difference between

garden sync-start api --deploy

and

garden deploy api --sync

except that the latter starts the dev console? So in terms of what gets built/deployed/synced to

Could someone add me to the Core release automation call? I'd like to understand better on how the process works and what's our plan in automating it

one thought i forgot to mention in core daily: could we try to make new releases for 0.12 and 0.13 today, some time after the automation call? we have a bunch of good little fixes to deliver to users

Just FYI: I do have a fairly important fix that I'm working on that essentially breaks the live page. I don't want it to block the release but we should in any case follow up with a second patch as soon as it's merged. I hope that'll be today, but likely end of day then.

And having been in the game for awhile, I also know that "hope that'll be today" should be taken with a grain of salt

How can i run a simultaneous instance of garden dev on diff port to avoid error (EADDRINUSE: address already in use ::1:9777)

Here are my thoughts from the release automation meeting in written form: https://github.com/garden-io/garden/issues/4520#issuecomment-1573869621

It's using

GARDEN_SERVER_PORT

var. e.g.

GARDEN_SERVER_PORT=9778 garden dev

Critical fix for the upcoming patch: https://github.com/garden-io/garden/pull/4526

PSA: I've found that bind mounts don't work in Docker Compose / vanilla Docker on Docker Desktop on macOS with virtioFS enabled. I suspect it's because I'm not on latest macOS. The gRPC Fuse option works fine though.

I've completed all my current tasks to the level where I'm waiting for something else so I'm picking up the next item from candidates which is looking into supporting k3s.

Hey all 🙂 Just to double check, do we still have the same process for reviewing and replying to GitHub issues from our community? Noticing a few we haven't responded to which is fine if they'll be addressed in the next triaging session. But wasn't sure what the current process is.

This came up in here https://github.com/garden-io/garden/pull/4516#discussion_r1214184810 Created a tracking issue here https://github.com/garden-io/garden/issues/4599 Timeboxed a very brief attempt into enabling this here https://github.com/garden-io/garden/pull/4601 Documented the leftover todos in the PR, feel free to pick it up whenever appropriate 🙇‍♂️

silly question: is there any sort of versioning for remote sources? besides the repo ref that is 🧵

Started implementing this with https://github.com/garden-io/garden/pull/4611 but i have some thoughts. This is not a bug per se as

jobs

are not managed by garden. A job can create one more more pods and continue to retry execution of the Pods until a specified number of them successfully terminate or the desired number of pods can't be started after specified retries. Making garden wait for the completion of jobs doesn't seem ideal as the nature of job could range from short-lived, parallel, or sequential batch tasks within the cluster to tasks like background data processing etc. @swift-garage-61180 and I discussed this already and would argue that if you need to wait for a deploy in your pipeline,

job

isn't the right resource and shouldn't be used.

exec

or

pod

would be more suitable. @icy-furniture-17516 As you originally reported the issue, what do you think?

I'm seeing microK8s 1.25 and 1.26 fail consisently (or a few times in a row) with the following error:

Error: Failed to create Pod api-test-98zjenxv: Got error from Kubernetes API (createNamespacedPod) - pods "api-test-98zjenxv" is forbidden: error looking up service account container-default/default: serviceaccount "default" not found

See e.g. here: https://github.com/garden-io/garden/pull/4575/checks Does this look like a flaky test error or like a legit error? It looks pretty "legit" to me and older versions of microK8s are passing. In case it is legit, I wouldn't think it's related to this PR since it shouldn't affect this test.

Have I corrupted my firefox or do the ci links from the latest main commit take you to the wrong ci run as well? Goes to shaky's branch for some reason.

That's a beautiful PR title: "fix: microk8s issues (and all the integ tests) #4629" https://github.com/garden-io/garden/pull/4629

Hey @curved-intern-91221 / @calm-family-29323, just wanted to mention that with 0.13.3 I still get the same issues with k3s in our Killercoda environment, I'm not sure if it's because we are using the

--forward

option in that demo? Here is a quick video to show the issue cc @quaint-dress-831

@curved-intern-91221 @brief-restaurant-63679 Are we still planning to do a release this evening?

Have we thought about persisting the history of garden commands run in a garden dev/serve session?

Kapa is suggesting 0.12 configuration: https://discord.com/channels/817392104711651328/1120389258683883692/1123732149841965187. cc @bright-policeman-43626 @quaint-dress-831

The default varfile format was changed to YAML in 0.13 see https://docs.garden.io/reference/project-config#varfile However the default varfile that does not need to be specified via the varfile config option, still needs to be garden.env and not garden.yaml which suggests it is in .env format. We explicitly say in our docs that the file extension determines the format. The behaviour right now is that garden.env works with .env content and yaml content. I think we can either change the documentation to reflect that or change the default varfile to reflect the yaml extension e.g. gardenvars.yaml Wdyt?

What do you think about removing the common action root configs from the reference docs and moving it to a separate reference? It's a lot of repetition and makes the references unnecessarily long. I propose to either link to the common action config or to have the common config collapsed by default so it's not in the way.