eysi09 released this
Jul 17, 2019
First of all, a big THANK YOU to our community for your contributions to this release!
Whether it's by helping us track down bugs, by submitting PRs (@theRealWardo, @johnraz, @dev-kpyc), or by giving us some much valued feedback.
The most requested feature after our last release was better secret support. With this release we take the first step towards that by allowing you to reference Kubernetes secrets in container modules. See our Kubernetes Secrets example for more details. We've also added the ability to only run certain groups of tests (or no tests at all) when in dev mode with the --test-name and --skip-tests flags. For example: garden dev --test-names=unit
garden dev --test-names=unit
Furthermore, we've made some changes to our release process. First of all, we'll now be uploading an edge release to Github on every merge to master. Second, we're moving to a weekly release cycle with releases every Tuesday afternoon (CET). This will allow us to respond faster to your issues and feature requests.
Beyond that, this one was all about squashing bugs!
eysi09 released this
Jul 16, 2019
chore(build): use static binary in container image builds
eysi09 released this
Jul 10, 2019
· 0 commits to master since this release
chore(release): bump version to v0.10.1-0
Note, the version in garden-service/package.json and
garden-service/package-lock.json is v0.10.1 instead of v0.10.1-0. This
is due to a bug in lerna that causes lerna bootstrap to fail when the
version number is a pre-release. This shouldn't matter since we'll
update the version anyway when we make the proper release.
thsig released this
Jun 27, 2019
· 8 commits to master since this release
When we first started working on Garden, eighteen months ago, we knew that developing systems locally was a stop-gap solution. With 0.10, we're taking another leap towards providing the best possible developer experience by letting you move your development workflow off your machine, into shared development clusters.
We've published a blog post describing our motivation behind all this.
Garden can now handle all building and testing in-cluster. This means you no longer need to run Kubernetes locally, but instead have a shared development cluster for your entire team. Each developer has a private namespace in the cluster, but shares the same build and test caches.
Think of how much time you, your team, and CI system waste downloading and building the same images, or testing the exact same combination of code. By moving your development to a shared cluster, each of these operations only needs to happen once.
For more information, see how to prep your cluster, and how to configure Garden to build remotely.
Another advantage of shared development environments is that you can call garden test from CI, pointing it at the same environment you developed in. This will spin up your stack and run all your tests—most of which will be cached from development. You can also use Garden in CI to spin up preview environments, or tear them down.
This greatly simplifies the average CI set-up, as you can get rid of all your scripts that would usually handle this, and no longer need to maintain separate configuration for development and testing.
For more information, see how you can use Garden in CI!
We’ve also included a large number of major and minor improvements and fixes, including much improves deployment status checks for Kubernetes workloads. We now “fail faster” and give much more information when issues are detected while deploying.
For the full list of changes (which is rather long), get a cup of coffee and peruse the changelog below:
k8s providers no longer default to /bin/sh -c as the entrypoint when running pods. This applies to tasks, tests and the run module command.
The --loglevel CLI option is now called --log-level
When using OpenFaaS with local-kubernetes you now need to use the local-openfaas provider, instead of openfaas. You also need to manually delete any existing <my namespace>--openfaas namespaces from your cluster after upgrading.