Do we have plans to make an 0.12 release some time soon?

Hasn't this been implemented already via the secrets copying logic that was added in 2022/2023? https://github.com/garden-io/garden/pull/1775

Team, excuse me for a ping on the weekend! looks like edge releases from

0.13

branch are setting

edge

tag instead of

edge-bonsai

. https://app.circleci.com/pipelines/github/garden-io/garden/17174/workflows/4b24087c-684e-4868-a2e1-7c8fd7727d93/jobs/294754 Also, seems like both

main

and

0.13

branches are playing ping-pong with the

edge

tag based on which branch gets the latest merge. for now, I manually SSH'd into a CircleCI runner corresponding the

main

branch's latest commit and ran the

edge-prelease

script to fix it. However the edge release gets replaced as soon as we have new merge in

0.13

branch (probably related to recent changes/introduction of edge-bonsai release(?))

We never did get this one merged—we should update the version of Mutagen we're using this week, since I'm sure there are a bunch of fixes & improvements we could benefit from by doing that. https://github.com/garden-io/garden/pull/3102

We have some test failures on the 0.13 branch now: https://app.circleci.com/pipelines/github/garden-io/garden/17208/workflows/3c6fccfd-1e81-4ff7-ab61-b98ea0dfac8f

Can I safely assume that

garden-0.13 cleanup namespace <env-name>

gives me the expected result similar to what

garden-0.12 delete env <env-name>

would result?

Have we completely removed sync mode from

exec

plugin? It looks like we have, and this example is no longer relevant: https://github.com/garden-io/garden/blob/0.13/docs/other-plugins/exec.md?plain=1#L84-L101 cc @calm-family-29323 @alert-helicopter-61082 @swift-garage-61180

What am I doing wrong?

ts
export const accessModesSchema = createSchema({
  name: "accessModesSchema",
  keys: {
    accessModes: joi
      .sparseArray()
      ... // other joi stuff here
    ),
  },
})

export const baseVolumeSpecSchema = () =>
  baseModuleSpecSchema().keys({
    ...accessModesSchema(),
  })

This results me with

Error: Schema can only contain plain objects

when attempting to render the docs

anyone else running into issues with our

terraform

provider on an arm-based mac?

@ancient-diamond-80011 did you look into upgrading to Node 20 at some point? Not thinking about pre 0.13 launch, just curious if we had poked at it. Had a chat with a user who'd love to see it due to a network issue that might be resolved with Node 20.

sorry, not yet 🙇‍♂️ we had a small thread here https://discord.com/channels/817392104711651328/1103003569654865941/1103003569654865941 and i created a tracking issue here https://github.com/garden-io/garden/issues/4158 it has already got quite a few reactions - people do want it 😅

awhile back I recall there being discussion of us making a migration tool to help folks with going from 0.12 modules to 0.13 style, basically making use of the code we're already using under the hood to convert the modules. did anything ever happen with that? are we still planning to do this? we've had some customers asking about it

I am updating the docs for garden workflows in bonsai and saw that we removed a lot of outputs from some commands e.g. build. These outputs were quite useful to reference as step outputs e.g. this workflow used to work in acorn because there were a lot of outputs available see https://docs.garden.io/reference/commands#outputs

kind: Workflow
name: test-outputs
steps:
  - name: build-images
    command: [build]
  - name: foo
    script: |
      echo ${steps.build-images.outputs.builds.api.version}"

But does not in bonsai because build now only has the outputs described here https://docs.garden.io/v/bonsai-release/reference/commands#outputs Is there an alternative way to get to this data now or did we decide to remove it entirely?

@swift-garage-61180 Am I right that the pulumi deploy spec shouldn't contain the baseBuildSpec schema? https://github.com/garden-io/garden/blob/0.13/plugins/pulumi/config.ts#L98 https://github.com/garden-io/garden/blob/0.13/docs/reference/action-types/Deploy/pulumi.md#specbuild

@calm-family-29323 @curved-intern-91221 pairing with veeti today, we had the idea to first merge main into 0.13 now-ish, instead of 0.13 into main on release day – there would be two advantages to this approach: 1. We can do it now, and see if our plan will work. On release day, it will be a fast forward merge to main without conflicts. 2. In the meantime we can verify that the merge did not introduce any regressions.

Is this the expected behaviour?

┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ Running sync start frontend... ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
✔ garden-enterprise    → Ready (in 0.1 sec)
ℹ providers            → Getting status...
✔ providers            → Cached (in 0.1 sec)
ℹ providers            → Run with --force-refresh to force a refresh of provider statuses.
ℹ graph                → Resolving actions and modules...
✔ graph                → Done (in 1 sec)
⚠ deploy.frontend      → Ignoring replicas config on container service frontend while in sync mode
⚠ deploy.frontend      → Resource Deployment/frontend is not deployed in sync mode, cannot start sync.
⚠ deploy.frontend      → Resource Deployment/frontend is not deployed in sync mode, cannot start sync.

Done!
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ ✓ sync start command completed successfully! ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈

quick question: do you plan to release arm binaries?

eventually, yes! here's a tracking issue https://github.com/garden-io/garden/issues/2333

I was asking because I created an asdf plugin for garden, but for now I hardcoded amd64 in it: https://github.com/pepov/asdf-garden feel free to try it out or take it over eventually, if you want to have it under your org

@icy-furniture-17516 Cool, good stuff! Thank you for creating this plugin. Feel free to add a comment to the ARM tracking issue @ancient-diamond-80011 mentioned above (https://discord.com/channels/817392104711651328/1088795679159222292/1109137421460840458), so we do not forget about it 👌

After the Bonsai release, we might get to this not too long into the future, I hope

@alert-helicopter-61082 Is the ${actions} context meant to be available only in action spec? For example this is not possible as of right now ```yml kind: Deploy description: The API backend for the voting UI type: helm name: api variables: repository: ${actions.build.api-image.outputs.deployment-image-name} tag: ${actions.build.api-image.version} ... ```

Could not find key actions.

One thing I'm noticing is that we're no longer publishing builds for Intel Macs. Did we stop doing that on purpose? @ancient-diamond-80011 @curved-intern-91221 @big-spring-14945

Not sure where to put this, but I think I have a major issue with edge-bonsai. I cannot set the namespace in the environment using defaultNamespace, because it will be prefixed with the project name. However when referencing it in a variable, it will only be the value I set (or simply default) Can someone confirm this is the case?

Could somebody please run

deploy

with latest 13 in the remote-sources example after deleting .garden dir and report back if it works 🙏 It works perfectly on my end but e2e is failing, maybe I have the sources caches somewhere idk

Anyone else running into issues opening PRs?

We have

garden create module

but is there no scaffolding available for actions?

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