Skip to main content

v1.5.0

The Kargo team is excited to announce one of our biggest releases to date -- Kargo v1.5.0!

Users will notice right away that the UI has been overhauled with extensive improvements to both usability and responsiveness, but this release has a lot of new and improved functionality under the hood as well, so let's dive in!

🆕 What's New?​

So many quality-of-life improvements have landed in v1.5.0 that we cannot give individual attention to each one, but here are some of the highlights:

  • Improved Project configuration:

    The Project CRD has historically had a spec field for defining Project configuration. In practice, this has been awkward to work with. Permission to perform various operations on Project-level resources (e.g. Warehouses, Stages, etc.) is managed at the Project-level (i.e. with ServiceAccounts, Roles, and RoleBindings in the Project's namespace). With Project resources themselves being cluster-scoped, permissions to update or delete them could not, themselves, be managed at the Project-level -- a quirk which has typically necessitated a Kargo (system-level) admin to either manually assign additional permissions to Project admins or else perform Project update or delete operations on their behalf.

    To eliminate some of this friction, Kargo v1.5.0 introduces a new namespaced ProjectConfig CRD. Being namespaced (Project-level), permissions to update or delete Project configuration can now be managed at the Project-level itself, and in fact, such permissions are now automatically granted to the Project-level kargo-admin Role when a Project and its associated namespace are created.

    The difficulty of self-service Project deletion for Project admins remains unresolved, but we anticipate this to be addressed in an upcoming release and in the meantime, eliminating the need for Project admins to lean on Kargo admins for Project configuration updates should be a welcome improvement.

    In concert with this improvement, the definition of promotion policies has moved from the Project CRD to the ProjectConfig CRD and received a large upgrade in the form of support for matching policies to Stages using patterns and label selectors.

    Note that upgrading to Kargo v1.5.0 from an earlier version will automatically migrate existing promotion policies from Project resources to new ProjectConfig resources. The Project CRD's spec field will be removed entirely in Kargo v1.7.0.

  • Improved bookkeeping for skipped promotion steps:

    Until now, when conditions specified using an expression in a promotion step's if field evaluated to false, causing a step to be skipped, the step was recorded as a success, despite never having executed.

    Beginning in Kargo v1.5.0, skipped promotion steps are explicitly marked as such.

  • Enhanced conditional promotion step execution:

    Kargo v1.5.0 also makes it possible to incorporate the cumulative result of prior promotion steps into conditions specified using an expression in a step's if field.

    • always() unconditionally evaluates to true, thus an expression like ${{ always() }} will permit a step to execute regardless of the outcome of prior steps. This is useful for implementing steps that contain cleanup logic.

    • failure() evaluates to true if any prior step has errored or failed, thus an expression like ${{ failure() }} will permit a step to execute only under those circumstances. This is useful for implementing steps that contain error-handling logic.

    • success() evaluates to true if all prior steps have either succeeded or been skipped, thus an expression like ${{ success() }} will permit a step to execute only under those circumstances.

    • When a step's if field is omitted, the step's execution is contingent on all prior steps having either succeeded or having been skipped, as if the if field had contained the expression ${{ success() }}.

    • It is also possible to directly access the status of an individual step using the status() function, thus an expression like ${{ status("my-name") == 'Errored' }} will permit a step to execute only if the step named my-name has errored.

    • Last, a new continueOnError field can be set to true to specify that a step that errors or fails should neither affect the evaluation of the failure() and success() functions as described above nor influence the overall outcome of the promotion.

  • ConfigMap access and improved Secret access in expressions:

    ConfigMap and Secret resources within a Project's namespace can now be accessed within expressions using new config() and secret() functions, respectively. For example, ${{ configMap('my-config').foo }} will access the value of the foo key in the my-config ConfigMap. ${{secret('my-secret').bar }} will access the value of the bar key in the in the my-secret Secret.

    Note the secret() function performs better than and replaces the existing secret map currently available in expressions, which has been deprecated and will be removed completely in Kargo v1.7.0.

  • Improved Workload Identity Federation support in GKE:

    Those running Kargo within Elastic Kubernetes Service (EKS) or Google Kubernetes Engine (GKE) may be familiar with Kargo's ability to use ambient credentials when accessing Elastic Container Registry (ECR) and Google Artifact Registry (GAR) repositories, respectively.

    For both of these, being a multi-tenant system, and in observance of the principle of least privilege, Kargo attempts to assume/impersonate Project-specific IAM roles/identities when accessing ECR and GAR repositories. On EKS, any failure to do so has automatically fallen back on attempting access using the controller's own ambient credentials directly. This has permitted administrators who may find it onerous to maintain Project-specific roles to grant permissions directly to the controller if strict adherence to the principle of least privilege is not a concern. On GKE, however, this option has not previously been available. Beginning in Kargo v1.5.0, it is, thanks to the diligent efforts of @kacpercesarz98!

New and Updated Promotion Steps​

  • The git-clone and git-commit promotion steps both now support the ability to specify optional authorship information, including signing keys, if so desired. When specified in either of these steps, that information overrides system-level defaults. Specifying authorship information in the git-clone step is a convenient way to extend that information to all commits made to a repository by subsequent git-commit steps. Any authorship information specified in a git-commit step takes precedence over any that was specified in the git-clone step.

  • The git-open-pr promotion step now exposes a pr.url field in its output, which can be used in subsequent steps. This is useful, for instance, to include a link to a PR in a Slack message sent via the http step.

  • The git-open-pr and git-wait-for-pr promotion steps now support Bitbucket thanks to @chamodshehanka.

  • The helm-template promotion step now supports directly setting the values of configuration keys directly in the step's configuration. This can be compared to using the --set flag in the Helm CLI to amend or override values specified in a values.yaml file.

🚨 Breaking Changes​

  • Functions commitFrom(), imageFrom(), and chartFrom() used within expressions to locate artifacts in a Promotion's Freight collection now return nil instead of an error when no matching artifact is found. This represents an added convenience, because Expr's nil coalescing and optional chaining features make a nil result easier to deal with than an error.

  • phase and message fields in Project and State statuses were deprecated in v1.3.0 and replaced with conditions. These deprecated fields have now been removed.

  • The messageFromSteps field of the git-commit promotion step, deprecated in v1.3.0 has now been removed, replaced with guidance to use expressions in the message field to construct commit messages.

  • The kargo.akuity.io/project-secret: true was added in v1.2.0 and promptly deprecated in v1.2.1 and replaced with kargo.akuity.io/cred-type: generic. Beginning with Kargo v1.5.0, this label no longer has any effect. Since this label and its effect were never documented, it is very unlikely that anyone has been using it, so listing this as a breaking change is a formality.

⚠️ New Deprecations​

  • The Project resource type's spec field has been deprecated (as described in "What's New?") and will be removed in Kargo v1.7.0. It is already invalid to create new Project's including a spec. Existing Project resources with a spec field will have a new ProjectConfig resource created for them automatically.

  • The Warehouse resource type's gitRepoURL field, previously used to link container image subscriptions to a related Git repository containing the image's source has been deprecated. This information may now be specified by annotating images with org.opencontainers.image.source at build time. Kargo has retrieved these annotations from container images since v1.4.0, and now leverages org.opencontainers.image.source to establish a link between container images and their source repositories. The gitRepoURL field will be removed in Kargo v1.7.0.

  • The secrets map in expressions deprecated, replaced with a new, better-performing secret() function (as described in "What's New?"). The secrets map will be removed in Kargo v1.7.0.

👋 Welcome Faris!​

The Kargo team is also excited to welcome a new maintainer -- @fuskovic!

If you notice improved promotion step timeout accuracy in this release, you can thank @fuskovic for that!

🙏 First Time Contributors​

As always, we would love to thank all first-time community contributors for their efforts! This release includes contributions from:

  • @hidalz
  • @Utwo
  • @IvanJosipovic
  • @fuskovic
  • @BWagenerGenerali
  • @schildwaechter
  • @mirrajabi
  • @han-steve
  • @sbyrne13
  • @Horgix
  • @Eslam-mohammed-anwar