Release Notes

Version 1.16.5
This version contains a fix for a bug that was causing authentication issues when using GitHub Enterprise Server.
Version 1.16.4
This version adds the possibility to specify a custom GitHub Enterprise hostname.
Version 1.16.3
This version contains some fixes for the Automatic Environment Cleanup functionality:
It is now possible to save the environment settings with an empty authentication script and schedule, which allows for disabling AEC.
A bug that would keep failing Cleanup runners alive is now fixed.
Version 1.16.2
This release contains a few bug fixes and upgrades to downstream dependencies. Notably:
A bug which would cause the creation of multiple webhooks when adding a project on GitLab
A bug in a dependency which would make secret resolution fail under certain conditions
and more are now fixed.
Additionally, we carried out a few tweaks and refinements on the UI.
Version 1.16.1
A follow-up patch release to 1.16.0 which ensures Jobs respect the Replicated node selector config field for on-prem deployments.
Version 1.16.0
This release contains a number of usability improvements. The biggest one is the new activity feed, which allows you to view activity across your project.
In this first iteration it shows activity related to VCS events and automatic environment clean-up runs.
Activity Feed
We'll be adding more activity types in the future, and we'd love to hear your feedback and ideas on what to include there. And, speaking of feedback, this release also adds a "Share feedback" button to the menu on the top right. We're looking forward to hearing from you :)
Other notable improvements include:
Environments can now be created and deleted from the UI. This can be useful if you need to add a secret to an environment before it's automatically created.
Added a search bar and environment filters to Secrets page.
The git branch name is now displayed on namespace rows for namespaces in which triggered workflows have run.
Added VCS info to triggered workflow runs on Namespace pages.
Workflow step names are now displayed in logs modal.
Version 1.15.2
This release improves the stability of workflow runner pods by using Core version 0.12.22 (which improves robustness against timeouts and network errors, and doesn't use NFS for kaniko builds).
We've also fixed a bug when re-adding repos to Garden Enterprise, making sure that duplicate projects don't get created for project configurations at the same relative path in the repo.
Finally, we've made some tweaks and improvements to the web UI.
Enjoy!
Version 1.15.1
This release significantly improves robustness and workflow runner pod logging, which makes Garden Enterprise's workflow runners more reliable and easier to use for challenging workloads.
Garden Enterprise now periodically checks for in-progress workflow runs with missing workflow runner pods, updates their status to "missing" and updates the workflow run's status in GitHub/GitLab.
This is very useful when running workflows that occasionally run into out-of-memory problems, and generally makes the system more robust during periods of high load or when the cluster is experiencing issues.
We now also stream the logs of the workflow to the runner pod log in real time to facilitate debugging. The log level can be customized in the Replicated console.
Additionally, we now keep timed-out workflow runner pods alive for five hours after marking the workflow run as timed out. This is done to facilitate debugging of timed-out workflows.
Note that if you haven't already enabled the Automatic Environment Cleanup feature flag, you'll have to fill in the In-Cluster Auth Token in your Replicated config. This is used to authenticate the CRON jobs used to check for missing/timed out workflow runs (as well as for Automatic Environment Cleanup). If you've already enabled Automatic Environment Cleanup, you'll have already provided this token (so there's no need to change your configuration for this release).
Happy hacking!
Version 1.15.0
This release introduces a major new feature: automatic environment cleanup.
We have also done a major design overhaul of the web UI! 🎉
New UI - Projects Page
Finally, we've added the ability to delete projects. This can be done from the new project Settings tab.
Enjoy!
Automatic environment cleanup (experimental)
With automatic environment cleanup, you can configure Garden Enterprise to automatically delete Kubernetes Namespace resources:
When the namespace hasn't been used by a Garden command for longer than a specified number of hours; or
At a specified time of day (or at a specified time on a given weekday). This cleanup can optionally be enabled on a per-environment basis, and the cleanup schedule for each environment can be set independently.
Automatic environment cleanup can greatly save on infrastructure costs by making sure that namespaces (and their associated resources) aren't kept around longer than needed.
This functionality is currently flagged as experimental. To enable it, please see our automatic environment cleanup guide.
Version 1.14.4
This release contains a handful of UI fixes and some performance improvements. In particular, we now automatically clean up dangling workflow pods and set their status to timed out.
Beyond that, we've been busy working on the Automatic Environment Clean-up (AEC) functionality along with some substantial UI polishing. We plan on releasing those changes next week.
Here's the full changelog:
Improvements
kots: set better values for liveness and readiness probes for kots manifests
api: automatically clean up timed-out runs
api: speed up workflows query
frontend: list usernames in failed imports
frontend: expose validation errors
frontend: show start time for long durations
frontend: avoid refetching user on focus change
Bug Fixes
api: ensure namespaces query filters on project
frontend: fix potential undefined environment
frontend: fix title size regression
Version 1.14.2
This release adds support for custom resource requests for workflow runners. See the workflows guide and the workflow config reference for more details.
As of this release, the workflow runner image includes the Azure CLI tools, which makes it easier to authenticate against Azure AKS clusters.
Version 1.14.0
With this release we make changes to how new users are added to Garden Enterprise. Please see below for more details.
This release contains several usability improvements and introduces a new way to add users to Garden Enterprise. In particular, users are no longer added via their GitHub/GitLab email addresses, but their GitHub/GitLab user names. You will find these on the user profile in the respective VCS provider, but in general you won't need to know the user name if you're using the new bulk user imports functionality.
Beyond that, we've been adding a handful of utility commands to the Garden CLI that allow you to list, create, and delete Garden Enterprise resources such as users and secrets. This can be very useful for performing bulk operations on these resources. We plan to release this with Garden Core in the next few days and will of course keep you posted.
Bulk User Imports (Experimental)
Note that this functionality is currently only available for GitHub users. GitLab users can however still do bulk imports via the CLI (see note above).
This functionality has been requested by many of our users. By enabling this feature in your Replicated config, you can now bulk import users from GitHub and assign them to a group at the push of a button. You can also filter on specific GitHub teams. For example, you can select all the members in your, say, developers team on GitHub, and import them to a corresponding developers group in Garden Enterprise.
Users Modal
This functionality is currently flagged as experimental. To enable it, you need to do the following:
Step 1: Enable the feature in your Replicated Config:
Experimental Features Config
Step 2: Update your GitHub App permissions. You must set the "Organization" level "Members" permission to Read-only and save your changes:
GitHub Members Permission
Step 3: Review and accept the changes from the Installed GitHub App page:
Review Request
We realise that it's inconvenient to have to update the permissions, but we explicitly always follow the principle of least privilege and will continue to do so. That's why we instead allows users to turn this feature on at their own convenience.
Prettier Logs Modal
We now make sure to chain related log entries together to provide better context and add highlighting as applicable.
Logs Modal
Filter on Environment and User
You can now filter on both the environment name and user name on the environment pages.
Namespace filters
K8s Manifest Changes
As you make the update and compare the two releases, you will notice that most of the manifests will have been renamed. This a necessary evil for us to better manage the different configuration options that we support. However, the resulting Kubernetes resources will materially be the same as before. If you have questions on this, don't hesitate to reach out.
Version 1.13.0
This release contains several improvements and a major new feature: Role Based Access Control (RBAC). We've also started publishing our release notes on this page.
Role Based Access Control
This is by far the star of the release and has been much awaited by many of our users. In short, you can now manage access at a much more granular level than before. In particular, you can control access at the environment level and for instance configure which group of users has access to secrets in which environments. If you're storing user credentials in Garden Enterprise, you can by extension control who gets to deploy into what environment.
You'll find detailed information and examples in our Roles and Permissions guide.
When you update Garden Enterprise, two groups will be created: the Admins group and the Developers group. Everyone in your team that had the Admin role will automatically get assigned to the Admins group, and everyone in your team that had the User role will be assigned to the Developers group.
You can now proceed to create your own custom groups and assign users as needed. Note however that the Admins group is built-in and can't be edited.
Here's an example of one such custom group:
Main Dev Team
Better GitLab Status Reports
GitLab doesn't support displaying statuses from integrations the way GitHub does with the Checks page. We now work around that limitation by posting Garden Enterprise workflow statuses as comments on the relevant merge request. Each workflow gets it's own comment, and when the status updates, we update the existing comment in place so as not to spam the merge request's comment section.
Here's an example of a GitLab event that matched on the deploy-preview-env and full-test-ci workflows.
GitLab Workflow Statuses
And here's an example of the same workflows after they've finished running:
GitLab Workflow Statuses
We've also added better support for different GitLab events and now we explicitly handle events that get sent when a PR is closed.
Base Branch Workflow Filters
We support setting a baseBranches filter on workflow configs. This is useful for running workflows on merges to your main branch, or any other base branch for that matter. Here's an example where we run a given workflow every time a pull/merge request is merged (not just closed), and the base branch is main:
1
kind: Workflow
2
name: deploy-to-staging
3
description: Deploy to staging when merging into the main branch
4
triggers:
5
  - events: [pull-request-merged]
6
    baseBranches: [main]
7
    environment: staging
Copied!
You can read more about workflow triggers in our Triggered Workflows guide.
Ensure Git Credentials in Workflow Runner
Previously, users had to manually configure git credentials in the workflow runner pods. We now ensure that the access token obtained from GitHub/GitLab for the specific workflow run is accessible to all git commands in the container. This means e.g. that if your workflow run requires a remote source, Garden can clone it without further configuration.
Note that we use the access token for the respective GitHub App / GitLab user. This means that it should have access to all repositories that need cloning. In the case of GitHub, you'll need to install the GitHub App on the relevant repositories. In the case of GitLab, you'll need to grant the associated user account access to the project.
Note that the access token only works for clones over HTTPS. You will need to configure git specifically for clones over SSH.
Enterprise - Previous
Environment Configuration
Next - Misc
FAQ
Last modified 2d ago