github kestra-io/kestra v0.20.0
on GitHub

latest releases: v0.16.15, v0.17.23, v0.19.16...
18 days ago

Features

Bug Fixes

Documentation

Code Refactoring

Chores

Commits

Breaking Changes

Label keys starting with system. are now reserved for internal usage in Kestra. Make sure that you don't use this prefix within your own custom labels. Read more about System Labels in the docs.

Conditions renamed

All conditions have been renamed without the Condition at the end. Aliases are in place, so all flows will still work, but you will see an information note recommending you to upgrade to the new name. Already deprecated conditions haven't changed to avoid extra overhead on your end.

Examples of renamed conditions:

  • io.kestra.plugin.core.condition.ExecutionStatusCondition → io.kestra.plugin.core.condition.ExecutionStatus
  • io.kestra.plugin.core.condition.ExecutionNamespaceCondition → io.kestra.plugin.core.condition.ExecutionNamespace
  • io.kestra.plugin.core.condition.ExecutionLabelsCondition → io.kestra.plugin.core.condition.ExecutionLabels

GCP plugin users

Pub/Sub messages were previously automatically base64-encoded before being published, and base64-decoded after consumption. This is no longer the case because Google Pub/Sub can handle binary and text data without the need for Base64 encoding.

For developers of custom plugins

The internal storage now takes a namespace parameter on all its methods. This is mandatory to be passed by a plugin but can be safely set as null in tests that directly use the internal storage. Plugins are normally not affected if they use the runContext().storage() method that has been updated to automatically use the execution's namespace.

EE: retrieving KV pairs from other namespaces

The kv() Pebble function was missing a check for allowed namespace in case a namespace is passed to the function e.g. {{ kv('MY_KEY', 'differentNamespace') }}. This check has been added in 0.20 release. If you use the kv() function to get a KV from a different namespace in the Enterprise Edition, make sure to allow access to this namespace (this happens by default unless explicitly restricted).

EE: Email server configuration moved to a different location

In Kestra < 0.20.0, email server configuration lived under kestra.mail-service. Given that it's used only within the Enterprise Edition (for resetting passwords and sending invites), we moved it to kestra.ee.mail-service.

EE: fallback on unhealthy workers

By default, a task configured to run on a worker group where no workers are available will wait for the worker to be available. The previous behavior was to fail.

This behavior is configurable. To keep the previous behavior, simply set the fallback behavior to FAIL as follows: 

  - id: hello
    type: io.kestra.plugin.core.log.Log
    message: Hello World!
    workerGroup:
      key: wg1
      fallback: FAIL #  possible values are WAIT (default), FAIL or CANCEL

If you want to set a custom workerGroup key and behavior per plugin type and/or namespace, you can leverage pluginDefaults.

EE: Usernames replaced by email addresses

Starting with Kestra 0.20, Kestra mandates the username to be an email address. If this is not the case within your instance, you can run the following CLI command to replace a username with the corresponding email for each user in the instance: 

./kestra auths users email-replace-username

If the email address is not set for the user or is invalid, Kestra will log those usernames so you can address those edge cases manually. If the username is already set as email, the above command will additionally set that value within the email property.

EE: Elasticsearch indexer

Starting with 0.20, if you are using the Kafka backend, there is no need to start an external indexer, even for the Kafka backend, as the webserver will start an embedded indexer automatically.

However, if you still want to start one, it is still possible to do so, and you can disable the webserver-embedded indexer by starting it with --no-indexer.

Starting an extra indexer should only be needed for very high throughput when you want the UI to be updated with very low latency about execution information. Most of the time, the webserver embedded indexer should be enough.

EE: for Kafka backend user

Due to a change in how we handle plugin defaults, the flow source needs to be available to the Kestra Executor. This change will sync the flow's source code with our queue allowing the executor to more efficiently apply pluginDefaults defined in the flow YAML configuration.

For users with a Kafka backend, this migration can be performed by running the following CLI command: 

./kestra sys-ee restore-queue --no-recreate --no-templates --no-triggers --no-namespaces --no-tenants

If you are using a Kestra version with the JDBC backend, this change doesn't apply to you, and you don't need to run the above command.

Check out latest releases or
releases around kestra-io/kestra v0.20.0

Don't miss a new kestra release

NewReleases is sending notifications on new releases.

Get notifications