I notice in our docs we set

RevisionHistoryLimit

to 10 if the

--production

flag is set. Is that correct? I don't see any reference to it in the source code?

Hi folks, very new to Garden as I am onboarding as a Platform Engineer at a new org. I wanted to get started with Garden as it is widely used here for deployments. However I immediately ran into issues after installing the cli via homebrew. Whenever I ran any command, I ran into an issue where the command invocation crashed abruptly due to an error with an api call to segment. I then disabled the telemetry and the issue no longer persisted. I am now able to use garden cli. I am attaching the error log that appeared on the console after any garden command. Is this a known issue at the moment? I was not able to find any open issues on github about the same. Also I can conform that the endpoint api.segment.io is not blocked where I am ( used multiple VPNs and still the same error, unless telemetry was disabled ). Thought I would report this here first. https://cdn.discordapp.com/attachments/1088795679159222292/1181148938242371635/error.log?ex=658001ab&is=656d8cab&hm=6809cf0970414069669d5dfdddea6ec03a2b6cf4253549e3c0e22631cd279eab&

Where we planning on doing a release today? I have a couple of things I'd love to get in and wanted to see how much time I have

Looks like I ran out of Kubernetes (ephemeral clusters that is) but the error message isn't very helpful:

ℹ providers                 → [kubernetes] Waiting for resources to be ready...
ℹ providers                 → [kubernetes] Deployment/default-backend: Waiting for rollout: 0 out of 1 new replicas updated...
⚠ providers                 → [kubernetes] Deployment/default-backend: Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "4dabd82e93f4ced89f660526f973eb846c4c40f182ae572593bc395cbc41391d": plugin type="flannel" failed (add): open /run/flannel/subnet.env: no such file or directory
✖ providers                 → Failed processing resolve provider ephemeral-kubernetes (took 30.9 sec). This is what happened:

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Timed out waiting for providers to deploy after 20 seconds
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Failed resolving one or more providers:
- ephemeral-kubernetes

See .garden/error.log for detailed error message

I can create a GitHub issue but just wanted to check first whether this was known a issue? Or for that matter something unrelated to me being out of minutes?

A quick fix to a problem that came up for a user who was trying to use the

scan.git.mode

  field in combination with the (now deprecated)

modules.include

/

modules.exclude

fields. https://github.com/garden-io/garden/pull/5626

I know that when you use

--force-refresh

then the providers will re-initialize. But in some other cases without this flag I have found them refreshing. My question is what specifically can trigger a provider refresh? I ask because I have start putting a lot of stuff into an

exec

dependency provider for e.g. starting minikube, setting up credentials, etc. and it can take a while to restore the cluster state since then everything needs to redeploy. Maybe this isn't a good idea in general but I just want to better understand how that mechanism as it isn't documented to my knowledge.

Another "how does it work" question. I'm using the

local-kubernetes

provider

tlsCertificates

option. Some description of what mechanically this actually does would be helpful. Does it copy the TLS secret to other namespaces?

@brief-restaurant-63679 I've now seen you mention that you will be deprecating the build subsystem. Is there a thread I can try to understand better?

And potentially comment or lobby in favor of keeping it

Heyo! would love some insight on this ticket whenever y'all have some time! https://discord.com/channels/817392104711651328/1220803228577435759

Hey y'all! Is there a way to remove this characters from my garden acorn deploy in Cloudbuild? https://cdn.discordapp.com/attachments/1088795679159222292/1226799555811741706/image.png?ex=6626151e&is=6613a01e&hm=cbcc5cf2f4354e9ee491e2cf8f65f7e4dc61093de0dc51c4b463fe7f6fd8376c&

Is there a timeline that shows how much time y’all are gonna support Garden 0.12? Need it to justify migrating to Bonsai

Hey y’all is there an easy way to manage different versions of garden per project? Like for example, tfenv allows to have a .terraform_version that controls the tf binary depending on the folder you are working on it

Adding on to the issue above, is there a way to be able to deploy both 0.12 and 0.13 to the same remote cluster? I have a CI cluster that I’m using to deploy with 0.12 but as soon as I get 0.13 I’m gonna get some issues because the garden-system namespace will conflict 😦

What is stopping you using 0.13.x CLI - it supports the 0.12 format in backwards compatibility - we were running that way until 2 months ago where we transitioned to 0.13 modules.

We are using some deprecated modules @big-solstice-45894 so need to make a parallel upgrade, while 12 is still running

Has anybody figured out how to use ts with Garden and sync mode? I was previously using ts-node but the project I’m working on moved to tsc+nodemon and that requires two containers to be up, one for compilation and one for runtime🥲 https://stackoverflow.com/questions/60581617/is-it-a-bad-practise-to-use-ts-node-in-production

Something pretty cool about the

kubernetes-exec

I love running the actions directly in the containers!

---
kind: Deploy
type: container
name: redis
description: Redis container edge-api-cc
spec:
  image: redis:5-alpine
  ports:
    - name: redis
      containerPort: 6379
  healthCheck:
    command: [redis-cli, ping]
---
# Run action for Redis clear task
kind: Run
type: kubernetes-exec
name: redis-clear
description: Redis clear task
dependencies: [deploy.redis]
spec:
  resource:
    kind: "Deployment"
    name: "redis"
  command: [redis-cli, flushall]

Seems like there's now a cooldown with the #1044642930075373588 so posting it here: # Issue with Project level variables and reusability Check this kapa post for context https://discord.com/channels/817392104711651328/1120389258683883692/1242341370438488194. In Garden 0.12 I was able to create variables in a single place and consume them all over my project. Using the following syntax

kind: Project
name: project
defaultEnvironment: local
dotIgnoreFile: .gitignore

variables:
  user-namespace: local-env
  base-hostname: local.app.garden
  # Globally usable
  RABBIT_URL: amqp://rabbitmq:5672
  REDIS_URL: redis://redis:6379

And then I was able to reference it from any kind of resource; tasks, helm deployment, etc. Example:

tasks:
  - name: migrations
    command: [/bin/sh, -c]
    args: ["npm run migrations:up"]
    env:
      RABBIT_URL: ${var.RABBIT_URL}
      REDIS_URL: ${var.REDIS_URL}

Now Garden detects them as circular references when I use it in Run actions for example.

kind: Run
name: migrations
type: container
spec:
  image: ${actions.build.api-image.outputs.deploymentImageId}
  command: [npm, run, migrations:up]
variables:
  RABBIT_URL: ${var.RABBIT_URL} # This gets detected as as circular dependency
  REDIS_URL: ${var.REDIS_URL}

Error:

Invalid template string (${var.RABBIT_URL}) at path RABBIT_URL: Invalid template string (${var.RABBIT_URL}): Circular reference detected when resolving key var.RABBIT_URL (var.RABBIT_URL)

This is definitely a bad experience because now I need to basically repeat the values in multiple spots or name the variables differently, which makes it incompatible with my 0.12 modules that I get as remote sources...

Hi @bright-policeman-43626! Thanks for the detailed writeup here. In the example you posted, there shouldn’t actually be a need to override the

RABBIT_URL

and

REDIS_URL

variables in the

migrations

action. Action-level variables function as overrides for the project/environment-level ones. So if you simply skip these lines:\

RABBIT_URL: ${var.RABBIT_URL} # This gets detected as as circular dependency
  REDIS_URL: ${var.REDIS_URL}

and keep these lines as they are:

tasks:
  - name: migrations
    command: [/bin/sh, -c]
    args: ["npm run migrations:up"]
    env:
      RABBIT_URL: ${var.RABBIT_URL}
      REDIS_URL: ${var.REDIS_URL}

The

RABBIT_URL

and

REDIS_URL

env vars should be read from the project-level variables without you needing to bring them in “manually” in the action-level variables. I do think it would be nice to be able to reference project-level variables in a template expression for an action variable with the same name, but we’d need to be careful not to break the circular dependency detection where it’s actually desirable. Hope this clarifies things! Are there any other blockers for you to upgrade to Bonsai?

Hi there, not sure how to really assign a reviewer to the PR I just pushed? https://github.com/garden-io/garden/pull/6236

Hi folks in your page https://docs.garden.io/overview/garden-vs-other-tools, "Internal developer portals (Backstage, Cortex etc.)" is not a heading as it should be

Hi @lemon-librarian-74479! Thanks for reporting this! I've fixed it in https://github.com/garden-io/garden/pull/6507

Hi, anyone could tell me if garden works with GCP with Autopilot?

hi! not sure if this is the right place, but anyone knows why this was closed? https://github.com/garden-io/garden/issues/3864

it is definitely a bug

Hi @fresh-raincoat-80017, from my understanding, the issue should have been resolved by the changes we made on how we stage builds for actions in 0.13.x. If that's not the case and you are still experiencing the bug, please do reopen the issue and we'll take a look.

moin

thanks! I see you reopened it already. I'll add a comment 🙂

Hey yes, I reopened it, since it seems like it's still a problem. I want to be upfront by letting you know that we are focusing on 0.14.0 for the next two weeks so we might not find the time to address it immediately. We are always open to contribution if you feel like. 🙂 But yeah, regardless, if you add any more detail that could help us debug it it would be much appreciated.