0.12.59

Garden 0.12.59 is out! 🎉

This is the maintenance release that fixes a few issues in the self-update command.
This also updates AWS CLI, Google Cloud CLI and Azure CLI to the latest versions.
That fixes the compatibility problems with Helm 3.12.

Assets

Download the Garden binary for your platform from below or simply run garden self-update if you already have it installed.

• Garden v0.12.59 for Alpine AMD64 (tar.gz)
• Garden v0.12.59 for Linux AMD64 (tar.gz)
• Garden v0.12.59 for MacOS AMD64 (tar.gz)
• Garden v0.12.59 for Windows AMD64 (.zip)

Changelog

Bug Fixes

• self-update: fix target release finding machinery (9aed119c5)
• self-update: fix list of the latest available versions (8f4df701b)

Other improvements

• dockerhub: update AWS CLI, Google Cloud CLI and Azure CLI to the latest versions to resolve helm issue #4571 (708e76f)

0.12.58

Garden 0.12.58 is out! 🎉

This is the maintenance release that fixes socket hang up errors.

Assets

Download the Garden binary for your platform from below or simply run garden self-update if you already have it installed.

• Garden v0.12.58 for Alpine AMD64 (tar.gz)
• Garden v0.12.58 for Linux AMD64 (tar.gz)
• Garden v0.12.58 for MacOS AMD64 (tar.gz)
• Garden v0.12.58 for Windows AMD64 (.zip)

Changelog

Bug Fixes

• k8s: handle intermittent socket hang up errors (51458c674)

0.13.1

Garden 0.13.1 is out! 🎉

This is a maintenance release. It includes a few bug fixes, minor features, and improvements.

Many thanks to @theoribeiro for the contributions to this release!

Assets

Download the Garden binary for your platform from below or simply run garden self-update if you already have it installed.

• Garden v0.13.1 for Alpine AMD64 (tar.gz)
• Garden v0.13.1 for Linux AMD64 (tar.gz)
• Garden v0.13.1 for MacOS AMD64 (tar.gz)
• Garden v0.13.1 for Windows AMD64 (.zip)

Changelog

Features

• add outputs to exec provider (7bd2a35da). Check exec docs for details.
• log exec stdout (f1a86aa2e)
• add new commands: (#4449)
  • get actions
  • get builds
  • get deploys
• update get runs, get tests command (#4449)
• update helm to 3.12.0 (8e8bc8093)

Bug Fixes

• fix pulumi stack rm tags error (#4533)()
• pulumi module validation (#4497) (a0d79f70d)
• conftest properly convert module (c8ac68792)
• terraform module validation (#4509) (15483b25d)
• properly wait for k8s deploys to complete (fdb4b6ffe)
• await configure provider handler call (2de39a015)
• escape rsync special characters in filenames on windows (#4434) (4fbc5de89)
• improvement to fetch-tools so it downloads only required binaries (3e8df6568)
• helm module to action conversion: do not require version with name (#4463) (947b91156)
• fix pvc modules to actions conversion (c1b153113)
• render (log) errors (#4439) (4fe827fc1)
• dev: plugins outside of core package weren't available in dev+server (adbd58ba6)
• exec: cleaning up persistent processes didn't work in some cases (a892b0f81)
• jib: tarPath resolution and project type detection (#4498) (08d87f31a)
• kubernetes: do not fail to deploy List kinds (e.g. ConfigMapList) (#4501) (25e1637b9)
• serve: fix help message of internal command (39db05d55)

0.12.57

Garden 0.12.57 is out! 🎉

This is a maintenance release. It includes a few bug fixes, minor features, and improvements.

Many thanks to @theoribeiro for the contributions to this release!

Assets

Download the Garden binary for your platform from below or simply run garden self-update if you already have it installed.

• Garden v0.12.57 for Alpine AMD64 (tar.gz)
• Garden v0.12.57 for Linux AMD64 (tar.gz)
• Garden v0.12.57 for MacOS AMD64 (tar.gz)
• Garden v0.12.57 for Windows AMD64 (.zip)

Changelog

Features

• update helm to 3.12.0 (64de8054f)

Bug Fixes

• escape rsync special characters in filenames on windows (#4434) (8247044a6) fixes #4018
• pulumi: fix pulumi stack tag rm error (59a054036)

0.13.0

Garden Bonsai (0.13) has been released! 🌳✨

This is a big new release, and we've been hard at work on it for several months. The main pieces are:

• Actions. Backwards-compatible with modules, these are a simpler and more flexible way to describe your dev workflows.
• An improved CLI experience. This includes a reimagined interactive dev command.
• Start/stop code syncing without redeploying. The sync start & sync stop commands give you finer-grained control over code syncing.
• Re-run tests and scripts without rebuilding. The inner loop of development just got even faster.

Below, we dive into these in a more detail.

We would love to hear your thoughts and feedback! If you encounter any bugs or have ideas for improvements or additional features, please open a GitHub issue for it.

For those of you who already have Garden projects from earlier versions, we recommend taking a look at the Bonsai migration guide in our docs.

Finally, we warmly welcome you to our Discord community, where we also do our development out in the open!

Breaking changes

Here is the list of breaking changes in Bonsai:

• The cert-manager integration has been removed. New documentation has been created in the ext dns and cert manager example
• dev-mode has been renamed to sync (and is now referred to as sync mode), both in configuration as well as in CLI command options.
• The garden delete command has been renamed to garden cleanup.
• garden delete env has been renamed to garden cleanup namespace, with an alias of garden cleanup ns
• Changes to project configuration:
  • The dotIgnoreFiles field has been renamed to dotIgnoreFile and only supports one file. The old dotIgnoreFiles field is still supported with a deprecation warning. Now it supports only 1 filename defined in the array, otherwise an error will be thrown.
  • The modules.* field has been renamed to scan.*. The old syntax is still supported with a deprecation warning.
  • Removed default environments (this might require you to explicitly specify a plugin name or two in your project config that were previously inferred implicitly).
• Template variable names will use camelCase everywhere, no more snake_case or kebab-case: tracking issue
• The deprecated hot-reload mode has been removed: Use sync instead.
  • Sync mode is faster, more reliable and more full-featured than the old hot reload mode, so we feel confident that you'll be happy with the upgrade.
• The deprecated cluster-docker build mode has been removed. Please use cluster-buildkit or kaniko instead.
• Dropped support for deploying an in-cluster registry
  • See the in-cluster build documentation for guidance on how to set up a container registry for using Garden with a remote Kubernetes cluster.
• Dropped support for the following providers:
  • google-app-engine
  • google-cloud-functions
  • local-google-cloud-functions
  • maven-container (superseded by the the jib-container plugin)
  • npm-package (the exec provider is a good replacement there)
  • openfaas

Actions: A simpler, more flexible way to describe your pipelines

Abstractions are all about noticing patterns.

That's where Garden's design came from—we noticed that almost all dev automation and CI pipelines boil down to a sequence of a few basic types of operations:

• Builds
• Deploys
• Tests
• Runs (for all those pre/post steps, e.g. to set up auth, or load DB schemas and data)

All of these have slightly different semantics (deploys, for example, have "liveness" semantics about being running or missing or unhealthy, whereas tests and runs only succeed or fail).

A framework that understands those semantics enables you to be a lot more expressive when defining your pipelines. This means way less boilerplate, and way less time spent debugging. Making life easier for engineers by capturing these common semantics in a batteries-included platform was why we built Garden to begin with.

Until now, Garden has grouped these operations into modules. The idea was that code and the operations performed on that code (building, deploying, testing and running) belonged under the same umbrella (a module).

Over time, we realized that it was simpler and more flexible to configure each of these operations as its own action (essentially breaking modules up into their constituent operations). Conceptually, this:

module
|-> build
|-> one or more deploys
|-> one or more tests
|-> one or more tasks (now runs)

now just becomes a list of Build, Deploy, Test and Run actions.

Actions are very close to how people already model the domain instinctively: What sequence of steps do I need to spin up this environment? Each of those steps now neatly fits into an action.

In the example below: We have a Docker image for a service that's deployed via a Helm chart. We've got unit tests and integration tests for the service, and we'd like to be able to do code syncing on the service.

Mapping this to actions is a lot more straightforward than it was with modules: A Build action for the Docker image (build.vote-image), a Deploy action for the Helm chart (deploy.vote) and Test actions for the unit & integration tests (test.vote-unit and test.vote-integ). These are all you need for a CI pipeline to deploy & test this service—or to deploy a dev environment with code syncing!

The net result: Going forward, it will be a lot easier to lay out your CI pipelines and dev automation with Garden.

That's the beauty of composable abstractions: No matter how complex your stack and your pipelines are, you can see at a glance how they decompose into a graph of actions.

It's a lot easier to build castles out of Lego than out of sand!

Actions are backwards-compatible with modules

Module configs still work in Bonsai—internally, Garden simply converts modules to their constituent actions on the fly. Over time, we recommend that you convert your module configs to action configs, since there are new and exciting capabilities that are only available in actions.

Any action can depend on any action

Dependencies have become a lot more flexible in Bonsai: Any action can depend on any action.

This is very useful e.g. when designing CI pipelines, where you only want to start an expensive Docker build if unit tests pass, and where you may need a run step to prepare things before a build or deploy can take place (e.g. run a script to configure authentication, or dynamically generate a configuration file that's used by a build).

A reimagined garden dev command—now interactive!

The garden dev command has been redesigned from the ground up.

When you run it, it loads your project, and opens an interactive prompt. You can then build, deploy and test, start or stop code syncing and stream service logs without exiting the command.

Since you don't need to load your project every time you want to perform an action, this makes for a very smooth inner-loop experience —especially when used in conjunction with the new sync start/sync stop commands and the new rebuild-free kubernetes-exec tests and runs (more on those below).

You can get the same fast feedback loops when code syncing and running integ/end-to-end/API tests in a production-like environment as you're used to when running and modifying unit tests for a single locally-running service.

All in all, we think the new dev command is a big step towards a truly first-class developer experience for Kubernetes!

Note: If you run garden deploy --dev|sync|forward, a dev command session that starts by running the requested command is launched instead. This means you always get the full-powered interactive experience, no matter which persistent command you use as the entrypoint.

Code syncing: More control and visibility

The new sync start and sync stop commands can be used to stop and start code syncing for one or more deploys.

When run inside the garden dev command, the syncs are stopped when the command terminates. When run outside the dev command, by default they stay running after the command terminates.

To see the status of any code syncs you've started, you can use the garden sync status command.

This will also show you diagnostic messages for any syncs that have been halted, which can happen if you move sync roots around or delete entire directories). The garden sync restart command is a convenient way to restart syncs after you fix any sync issues.

All in all, being able to stop and start syncs without having to redeploy can save a lot of unnecessary rebuilding during development, which will hopefully come in handy for all of us using Garden's code syncing throughout the workday!

Lightning fast tests & runs with kubernetes-exec

Bonsai ships with two types of test and run: kubernetes-pod and kubernetes-exec.

kubernetes-pod is the classic type of test and run, familiar to users of 0.12. When a kubernetes-pod test or run is triggered, a one-off Pod using the appropriate image is deployed, and the test/run's command is executed in the pod (after which is it terminated).

While this is a great fit for most CI use-cases, it isn't ideal for use with code syncing, since re-running a test/task will require rebuilding the ...

0.13.0-1

chore(release): release 0.13.0-1

0.12.56

Garden 0.12.56 is out! 🎉

This is a maintenance release. It includes a few bug fixes, minor features, and improvements.

Many thanks to @bxsx for the contributions to this release!

Assets

Download the Garden binary for your platform from below or simply run garden self-update if you already have it installed.

• Garden v0.12.56 for Alpine AMD64 (tar.gz)
• Garden v0.12.56 for Linux AMD64 (tar.gz)
• Garden v0.12.56 for MacOS AMD64 (tar.gz)
• Garden v0.12.56 for Windows AMD64 (.zip)

Changes to container images on Docker Hub

• The images at hub.docker.com/gardendev/garden-full are no longer receiving updates from this release on. The repository will be removed in the future.
• The way we tag images at hub.docker.com/gardendev/garden, hub.docker.com/gardendev/garden-gcloud, hub.docker.com/gardendev/garden-azure, hub.docker.com/gardendev/garden-aws, hub.docker.com/gardendev/garden-aws-gcloud and hub.docker.com/gardendev/garden-aws-gcloud-azure changed according to #3993. Old tags may continue to work, but won't receive further updates.
• The new tags for the latest 0.12 releases are 0.12-$flavor and acorn-$flavor, for example 0.12-alpine or acorn-alpine. As soon as 0.13.0 (First stable Bonsai version) has been released, the latest tag will refer to 0.13 (Bonsai) releases.

Changelog

Features

• add self-managed state backends to pulumi stacks (#4107) (d52b821e6)
• plugins: set the manifest to unknown if repository is not found (cac507311)

Bug Fixes

• circleci: bash typo in release-dockerhub (#4249) (ea454bd5e)
• k8s: stop retrying in LogFollower when Pod is in terminal phase (#4131) (1dea5419a)

Improvements

• container: redeploy when spec changes (f0bd691d9)

0.12.56-1

chore(release): release 0.12.56-1

0.12.56-0

chore(release): release 0.12.56-0

0.12.55

Garden 0.12.55 is out! 🎉

This follow-up patch release fixes the regression in project-level variables resolution introduced in 0.12.54.

Assets

Download the Garden binary for your platform from below or simply run garden self-update if you already have it installed.

• Garden v0.12.55 for Alpine AMD64 (tar.gz)
• Garden v0.12.55 for Linux AMD64 (tar.gz)
• Garden v0.12.55 for MacOS AMD64 (tar.gz)
• Garden v0.12.55 for Windows AMD64 (.zip)

Changelog

Features

• retry k8s api calls on ECONNREFUSED and 500 errors (64cdeabdb)

Bug Fixes

• revert: remove noProject flag from custom commands (016c5eab9)