Hey all Just to follow up on that issue with the source paths we bumped into in our collab session yesterday. AFAICT, Garden isn't handling the

source.path

field correctly when using the

getFiles

handler on the VCS class. It looks like its just ignoring it which means it thinks a give action doesn't have any files. For example, consider the following config:

# In api/garden.yml
kind: Build
name: api
type: container
source:
  path: ../ # <-- Set the source to the parent dir
include: [api/**/*]
---
kind: Deploy
name: api
source:
  path: ../ # <-- Set the source to the parent dir
spec:
  files: [./manifests]

In this case the build context for the build action will be empty and the build fails with the error that a Dockerfile wasn't found. The Deploy appears to work because at deploy time we read the files from the correct path and Garden applies the manifests. However—and this is important!—because the files are still empty the action version is incorrectly calculated. So if you e.g. update the manifests, the version will not change. First off, am I doing something wrong here? If not, this needs to be addresses ASAP. cc @curved-intern-91221 @swift-garage-61180 , because this is pretty deep in the engine.

I'm also noticing an issue where Garden can't connect to the dashboard on latest main but our latest release works fine. Just flagging so we don't release before the issue is resolved. I'm debugging as we speak and have at least one culprit in mind. cc @curved-intern-91221 @astonishing-tomato-18259 @big-spring-14945

Starting a thread on the "unversioned config keys" feature we were talking about yesterday 🧶

I notice the e2e tests for https://github.com/garden-io/garden/pull/5306 keep failing with

RequestError: getaddrinfo ENOTFOUND test.cloud.garden.io

AFACIT this also happens on main and is not related to my changes. I'm not super hip to the changes we've been making around the e2e tests though. Anything silly I'm missing here? Is that address supposed to actually exist?

Starting a thread on the remaining

reexamine-post-0.13

GitHub issues to be triaged. 🧵

@chilly-gigabyte-83853 turns out the issue we saw with the non resolving template strings is a known issue https://github.com/garden-io/garden/issues/3989

@curved-intern-91221 Thank for flagging this. I'm kind of surprised this isn't already covered by unit tests, but we should investigate & fix ASAP. I think this should be relatively straightforward. Do you feel like having a go yourself, or should we find someone else? https://github.com/garden-io/garden/issues/5317

This issue title made me smile: https://cdn.discordapp.com/attachments/1088795679159222292/1169222012607135794/Screenshot_2023-11-01_at_11.30.10.png?ex=65549dda&is=654228da&hm=64d813501ddc5df20a2e3b6f0703e3e618f9b825737853c1a1f5621c62155e52&

I'd love to hear your thoughts/comments on this, @brief-restaurant-63679 @alert-helicopter-61082. https://github.com/garden-io/garden/pull/5329

I’m not quite clear on why/how this fixes the issue. Could we throw in a test as well?

Hello, I have an issue where "actions" and maybe others...outputs vars never seem to interpolate in manifests, the applied yaml has the literal string

${actions.build.<name>.outputs.deploymentImageId}

instead of the value.

This works fine with other vars like

${environment.namespace}

Example below...

Kind: Build
name: web
type: container
...
...
---
Kind: Deploy
type: Kubernetes
name: web
source:
  path: ../manifets
spec:
  files:
    - deployment.yaml
---
# deployment yaml in manifests dir
apiVersion: apps/v1
Kind: Deployment
....
...
spec
  image: ${actions.build.web.outputs.deploymentImageId} #literally prints this
  image: ${environment.namespace} #this interpolates just fine

Starting a new thread for the issue surfaced here: https://discord.com/channels/817392104711651328/1169365561302597813/1169389901800816761 Can we validate this properly? Depending on the use case, it can be quite hard to spot unresolved template strings in K8s manifests (e.g. if they're used in env vars). Here I'd like Garden to catch that I'm referencing an output from an action that my downstream action doesn't depend on and show me an actionable validation error—or simply create the dependency implicitly.

Just realised that this one is still open. Could we get it reviewed and merged? Or do we not think this is the right way to go? CC @alert-helicopter-61082 @brief-restaurant-63679 https://github.com/garden-io/garden/pull/4957

Great catch! We should definitely get this over the line assuming @alert-helicopter-61082 's comments have been addressed.

I noticed a regression introduced by this PR of mine: https://github.com/garden-io/garden/commit/aaaf6d5f4ef868b5b591c35b20ee046f3a5fed85 It happened when I was playing with a project that uses config templates. Let's hold off on making the next Core release until I've fixed that, shouldn't take long. CC @curved-intern-91221

Ok, here's a fix to the regression: https://github.com/garden-io/garden/pull/5345

I notice that when executing a given action fails we log the fail count and also include downstream dependencies. However, we don't actually log anything for the the downstream deps themselves. E.g., in the vote example, if deploying the API fails and we're doing a full deploy, Garden will log:

2 deploy action(s) failed!

...because it's counting

api

and

vote

which is downstream dep. We get the fail count here: https://github.com/garden-io/garden/blob/main/core/src/commands/base.ts#L1041 This is kind of confusing because otherwise we don't log anything about the

vote

action. Can we also log for each downstream action that they have been aborted? In this case I'd expect something like:

ℹ deploy.vote   → Aborting because executing upstream dependency "deploy.api" failed.

And same for other potential downstream actions.

While looking into [this issue](https://github.com/garden-io/garden/issues/5317), I noticed that the logic for parsing Dockerfiles and computing includes from them is only being used for module configs (not action configs). I.e. the

containerHelpers.autoResolveIncludes

helper. Was this done on purpose (i.e. did we decide to deprecate the automatic inference of includes from Dockerfiles but still support it for current module configs), or should I fix that while I'm at it? @alert-helicopter-61082 Also CC-ing @big-spring-14945 since he recently did some fixes in this part of the codebase.

That is not intentional, no.

Do we have any concerns about making

GARDEN_GIT_SCAN_MODE=repo

the default? It's faster on all platforms, but significantly faster on Windows due to Windows having a high overhead for spawning subprocesses, and the

subtree

mode spawns a lot in larger projects.

All those dependabot PRs merged in like butter now (https://github.com/garden-io/garden/pulls?q=is%3Apr+is%3Aclosed) after I added a retry regex for a weird flake that popped up lately on microk8s: https://github.com/garden-io/garden/pull/5383 The CI seems to be reliable again now with this in core 👍

PSA: We've [centralized all terminal ANSI styles in a single map](https://github.com/garden-io/garden/pull/5375) and replaced calls to

chalk

with calls to

styles

. In most cases you shouldn't have to apply styles at all since the logger applies sensible defaults. But if you do, you should use

styles

instead of

chalk

. E.g.,

styles.highglight

instead of

chalk.cyan

The goal is to keep this consistent and also to make it easier to change styles (e.g. change

styles.primary

from one color to another). There's also styles for common "elements" such as

styles.link

,

styles.command

and

styles.section

. Using

styles

instead of

chalk

is otherwise not enforced at the code elvel but we can revisit if things start drifting again.

I feel like our current edge release works pretty well. When do we want to release it?

Can someone give me an approval for the rust refactors? https://github.com/garden-io/garden/pull/5359 I can also give a rust intro in the next show and tell if nobody feels like reviewing rust code 🙂

What's the primary use case for the

build

field on actions. The docs are a little unclear on this: > Specify a Build action, and resolve this action from the context of that Build. > For example, you might create an exec Build which prepares some manifests, and then reference that in a kubernetes Deploy action, and the resulting manifests from the Build. If I e.g. have a Test action of type container that depends on some build, should I specify that here? Or should I rather just set the image for the Test action like so:

- kind: Test
    name: my-test
    type: container
    dependencies: [my-build]
    spec:
      image: ${actions.build.my-build.outputs.deploymentImageId}
      args: [npm, test]

How do I avoid that "prebuild-file-path" line that's always console logged when running a dev build of Garden?

Should we get rid of this warning in the next release? > Garden v0.13 (Bonsai) is a major release with significant changes. Please help us improve it by reporting any issues/bugs here: > https://go.garden.io/report-bonsai

We can remove the "rosetta" requirement, right? https://cdn.discordapp.com/attachments/1088795679159222292/1179825393516159079/Screenshot_2023-11-30_at_17.43.30.png?ex=657b3105&is=6568bc05&hm=61af49ca1d774b035e69a889d3a135af9714176e792b0b36f7e25c0e378d5d56&

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?