akuity/kargo v1.1.0 on GitHub

💪 The Kargo team, with support from community contributors, is proud to present v1.1.0 -- Kargo's first minor but mighty release since going GA.

🆕 What's New?

${{ Expression Language Support }}

The community reception to Kargo's transition away from its rigid, legacy promotion mechanisms, toward more flexible promotion steps has been overwhelmingly positive. When promotion steps first appeared in v0.9.0, we knew immediately that support for an expression language would be a powerful complement to that new feature, and this release delivers on that.

For more details, consult our expression reference documentation. Examples in our promotion steps reference documentation have also been extensively updated to reflect realistic usage of the expression language.

With the advent of expression language support in promotion steps, we're noticing our own promotions processes becoming more and more similar from Stage to Stage -- often varying only in the definition of a few key variables. With this observation, it's clear that the time is right to promote (pun fully intended) promotion processes to a first-class construct. So, to tease the upcoming v1.2.0 release, expect to see a new PromotionTemplate CRD that will enable users to DRY up their pipelines!

🪜 New and Updated Promotion Steps

‼️ This section contains important details about deprecations. ‼️

When promotion steps were initially introduced without expression language support, many promotion steps included fields explicitly designed to reference the output of previous steps. For example, the git-wait-for-pr step has a prNumberFromStep field whose value should be set to the alias of a previous git-open-pr step. With expressions, these sort of highly-specialized fields become unnecessary and have been deprecated and scheduled for removal in v1.3.0. In their place, are new fields that, combined with expressions, offer improved flexibility. The aforementioned git-wait-for-pr step, for example, now has a prNumber field whose value might be set using an expression such as ${{ outputs['open-pr'].prNumber }}.

Two new promotion steps have been added in this release:

yaml-update, with the help of expressions, presents a more generic and flexible alternative to the helm-update-image step, which is also now deprecated and scheduled for removal in v1.3.0.
http provides a flexible means of interacting with HTTP/S endpoints. This opens up the possibility of simple, low-level integration with external systems that support webhooks or expose RESTful APIs. It is easy, for instance, to use the http step to post a message to a Slack channel as part of a promotion process.
While we plan for more complex integrations with external systems to be phased in over a series of releases in the form of support for third-party or site-specific promotion steps, we believe that in the interim, the http step will provide a powerful and flexible means of integrating with a wide variety of systems.

Two steps have been updated:

argo-cd-update has undergone some behavioral changes. Until now, the step, which registers health checks to be performed in the course of Stage reconciliation, has automatically attempted to infer a specific desired revision (e.g. a Git commit SHA) to which the Application being updated should be observably synced to in order for the Stage to be considered healthy. This behavior has been the foundation of some difficulty for users who have multiple Applications tracking the head of a single branch and who update that branch from multiple Stages. Under such circumstances, it becomes impossible for all such Stages to be healthy simultaneously.
To correct for this, the argo-cd-update step now makes no attempt to automatically infer the desired revision and will only factor the revision to which an Application is synced into a health check when the desired revision has been explicitly specified in the step's configuration. This change in behavior is technically a breaking change, but as it relaxes a constraint rather than imposing a new one, we do not anticipate any significant impact to existing uses of the step.
git-open-pr has been prone to errors when a PR identical to the one it attempts to create already exists. There were a variety of complex conditions that may have precipitated such a scenario. The step (and parts of the step execution engine) have been refactored to make the step more resilient to this possibility. When a PR identical to the one the step intends to create already exists, the step will now simply "adopt" that PR and proceed as if successful.

Last, but not least, all steps can now be configured with an optional timeout and error threshold. An error threshold greater than the default of one specifies the number of consecutive failed attempts to execute the step must occur before the entire Promotion is failed.

Please refer to the promotion steps reference documentation for detailed information about new and updated promotion steps as well as deprecated steps and fields.

⚙️ Resource and Concurrency Settings

This release introduces a number of optimizations to Kargo's resource utilization.

GOMAXPROCS is now set on all Kargo components to equal the CPU cores available, rounded up to the nearest integer. This prevents Go from backing goroutines with a number of OS threads exceeding the number of cores available, which is a condition that can result in losing compute time to avoidable context switches.
GOMEMLIMIT (soft memory limit) is now set on all Kargo components to equal the container's memory limit. This helps Go to optimize garbage collection.
MaxConcurrentReconciles now defaults to four (instead of one) for all reconcilers in both the controller and management controller. These defaults are overridable on a per-controller or per-reconciler basis via chart configuration at install-time.

To assist in troubleshooting, effective values for all of the above are logged by each component at startup.

🛠️ Refactored Stage Reconciliation

The controller's Stage reconciliation logic has been overhauled from top to bottom. The new implementation is more robust, more efficient, and should prove easier to maintain over time. We anticipate the refactored reconciler to also reduce the incidence of inconvenient behaviors such as pending Promotions being "stuck" for long periods of time while waiting for a Stage to reach or return to a healthy state that it may never reach.

For the most part, these changes are purely internal, but users may notice that the reconciler now surfaces much more detailed information about the state of a Stage in its status subresource in the form of conditions. These should paint a clearer picture of what's happening with a Stage at any given time.

🖥️ UI Improvements

As always, the Kargo UI has received too many improvements to list in this release. Here are a few highlights:

New Warehouses can now be interactively configured using a new UI wizard.
The UI's homepage, which lists all Kargo Projects, now remembers what page of the paginated list the user was last viewing. This means that users returning to the homepage after navigating to a Project will be returned to the same page of the list they were viewing before.
Within the view of a single Project, it is now possible to zoom in/out on the pipeline graph and drag to reposition it. This should make it considerably easier to work with long pipelines or Projects containing many pipelines.
A new user information page accessible from the sidebar displays the currently logged-in user's claims obtained from the identity token issued by the configured' OIDC identity provider. We anticipate this page will be useful for debugging OIDC configuration issues as well as authorization issues.

🙏 New Contributors

Thank you to the following community members whose first contributions to Kargo were included in this release:

Full Changelog: v1.0.4...v1.1.0