2.20.1
Release Links#
- lagoon v2.20.1
- lagoon-ui core-v2.20.1
- lagoon-build-deploy core-v2.20.1
- lagoon-core chart 1.47.0
Release Notes#
This release resolved a couple of minor issues discovered after releasing the 2.20.0 release.
Upgrades#
This release contains changes that you may need to be aware of. Read carefully before you upgrade.
Harbor 2.1.x and earlier#
- This release removes the support for Harbor from the Lagoon API. If you're still using the Harbor support in the API, you should NOT upgrade until you have configured your
lagoon-remote
installations to use Harbor instead. See the documentation here and read the section about Harbor. - We also recommend that if you're using Harbor version 2.1.x and earlier, that you upgrade this as soon as possible. Follow any instructions that Harbor recommend for upgrading. As of this release,
lagoon-remote
has been tested up to Harbor version 2.10.0 (helm chart version 1.14.0). Lagoon will stop supporting Harbor 2.1.x and earlier in a future release.
Deprecations#
Kubernetes minimum supported version is now 1.25, tested up to 1.30#
- The minimum supported version of Kubernetes is now 1.25, owing to deprecations in some core API functions, and the availability of upstream charts. The v2.20.0 release will not install into an earlier version of Kubernetes, so any Kubernetes upgrades will need to be performed prior to the Lagoon update.
Deleted Backups#
- When a backup is deleted via the webhook, it will now actually be removed from the API rather than being flagged as deleted. The
Backup
type fielddeleted
is deprecated, and will be removed in a future release. Additionally,includeDeleted
if requested when querying backups will not change the result as there will be no deleted backups to include.
API Harbor support#
- In 2.17.0 we announced that Harbor support in the API was deprecated. This release of Lagoon removes all support for Harbor from the API. See upgrade notes above.
DeleteAll/RemoveAll mutations removed#
- This release removes all
DeleteAllX
andRemoveAllX
from the API. These were only ever meant for local development and are no longer relevant.
Error handling on deployment triggers#
- In the past, if triggering a deployment using any of the
DeployEnvironmentX
mutations and an error was encountered, the API would not return an actual error, just a string that contained the error. This was changed in this release to actually return an error now. As this is a change in behaviour, it may impact any users that may have previously been capturing the string error text and parsing it to check for errors.