Skip to content

feat(deps): update kargo docker tag to v1.6.2

simon oscarrequested to merge
renovate/kargo-1.x into main

This MR contains the following updates:

Package Update Change
kargo minor 1.2.3 -> 1.6.2

Release Notes

akuity/kargo (kargo)

v1.6.2

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.6.1...v1.6.2

v1.6.1

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.6.0...v1.6.1

v1.6.0

Compare Source

The Kargo team is excited to bring you v1.6.0, which delivers several eagerly anticipated features! Let's take a look!

🆕 What's New?

🪝 Webhooks

In Kargo's initial prototype nearly three years ago, we relied exclusively on webhook requests sent by external platforms like GitHub or Docker Hub to inform Kargo of the existence of new artifacts. As anyone who's worked with webhooks before likely knows, webhooks are not an entirely reliable means of notification. If your server is down, a missed notification is missed forever. ☹️ It wasn't long before we changed our approach to Warehouses that periodically poll for new artifacts in a process we call "discovery." Although more reliable, discovery can be very inefficient. Even with aggressive caching on the Kargo side, architectural idiosyncrasies of OCI registries (used for container images or Helm charts) can make discovery a very "chatty" process. ☎️ Given that Kargo can execute a finite number of these processes concurrently and given that many OCI registries aggressively enforcement rate limits, system-wide performance of Warehouses can be quite... slow. 🐌 Although Warehouses poll for new artifacts every five minutes (by default) under nominal conditions, poor Warehouse performance could result in much, much longer intervals before Kargo effectively notices new artifacts.

One can easily see why it would be desirable to avoid executing discovery processes frequently if occurrences of those processes actually finding new artifacts is, comparatively, infrequent. So, counter-intuitively, configuring Warehouses to execute their discovery processes less frequently could improve system-wide performance -- at the expense of individual Warehouses still not noticing new artifacts any faster than before.

The ideal solution to this conundrum is for scheduled discovery to occur at much greater intervals (i.e. much less frequently), but for Warehouses to be notified when an ad-hoc discovery process would be guaranteed to find new artifacts (which we do not wish to depend upon exclusively since such notifications are less reliable). Thus, Kargo v1.6.0's "anchor feature" is the introduction of robust webhook support. ⚓

Webhook receivers for popular Git hosting platforms and OCI registries are easily configured at the Project level (using the ProjectConfig resource introduced in v1.5.0) or at the system level using a brand new ClusterConfig resource. A webhook receiver configured at the Project level will prompt Warehouses within the Project to execute discovery of new artifacts only if they are subscribed to the repository from which an inbound webhook request originated. A receiver configured at the system level will do the same for Warehouses across all Projects. These receivers make it practical for Project admins and Kargo system admins alike to reduce the frequency of discovery processes that are less likely to find new artifacts and still execute a discovery process promptly when new artifacts are guaranteed to be found.

v1.6.0 delivers webhook receivers for the following platforms, with more to come in future releases:

  • Bitbucket
  • Docker Hub
  • GitHub (and GHCR)
  • GitLab
  • Quay.io

For general information and "how-tos" pertaining to webhook receivers, refer to Kargo's Working with Warehouses documentation. Individual receivers each have their own reference documentation as well.

⚠️ Webhook support is currently in beta, meaning the Kargo maintainers caution that your mileage may vary and that breaking changes to this feature in upcoming releases remain a possibility. To explain this caution, and for the sake of transparency, we will cite a current problem with this new feature. If a Warehouse subscribes to some specific branch of a Git repository (let's say main), a webhook request notifying Kargo of a push event to that repository will trigger that Warehouse's artifact discovery process even if the push were to some other branch (for example, a feature branch or Stage-specific "rendered" branch). The same applies to container image repositories. If, for instance, a Warehouse subscribes to semantically versioned images in some repository, but is notified that an image tagged non-semantically has been pushed, that Warehouse's discovery process will still execute. Depending on the level of activity in your repositories, you may wish not to use this feature yet. The Kargo team is intent on optimizing our webhook support in the v1.7.0 timeframe so that details of a Warehouse's subscriptions are utilized to filter events and prevent unnecessarily triggering discovery processes.

💥 We are just getting started where webhooks are concerned. With the general framework now in place for receiving and acting on notifications from external systems, we intend to speed up other parts of Kargo. For instance, we may begin using notifications of MRs being merged (or closed unmerged) to resume any applicable Promotion currently paused on a git-wait-for-pr step.

🎂 Other Features

With the Kargo team having been so intently focused on webhooks, all the other features are the icing on the proverbial cake. But this frosting is tasty!

Here is a non-exhaustive list of notable features included in this release:

  • Stages with a single upstream Stage now have an option in the UI to promote whatever Freight is present in the upstream. (Think of this as "pulling" from upstream.)

  • When promoting Freight to a Stage using the UI, remaining soak time before a given promotion is permitted is now displayed (when applicable).

  • For Kargo instances authenticating users via Open ID Connect, all claims from a logged-in user's identity token are now visible to that user on the user page. This is expected to be helpful to users and administrators alike when troubleshooting permission problems.

  • ProjectConfig resources introduced in v1.5.0 can now be created, edited, and deleted via the UI. The newly introduced ClusterConfig resources can also be managed through the UI.

  • ConfigMap resources can now be created, edited, and deleted using the UI.

  • Warehouse subscriptions to Git repositories may now utilize expressions to to select or ignore commits on the basis of commit metadata.

  • Beta: Kubernetes namespaces "adopted" by Kargo Projects can be configured to be retained (instead of deleted), when the Project is deleted.

🚨 Breaking Changes

  • The git-commit promotion step will now complete with a Skipped status instead of Succeeded if it detects there no diffs in the working tree.

⚠️ New Deprecations

None

🙏 First Time Contributors

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

Full Changelog: https://github.com/akuity/kargo/compare/v1.5.3...v1.6.0

v1.5.3

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.5.2...v1.5.3

v1.5.2

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.5.1...v1.5.2

v1.5.1

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.5.0...v1.5.1

v1.5.0

Compare Source

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 MR 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:

v1.4.4

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.4.3...v1.4.4

v1.4.3

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.4.2...v1.4.3

v1.4.2

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.4.1...v1.4.2

v1.4.1

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.4.0...v1.4.1

v1.4.0

Compare Source

🆕 What's New?

Kargo v1.4.0 is more than meets the eye. While we do have a few new features to share with you, a lot of the team's recent work has been less obvious. We've been hard at work paying down some technical debt, cleaning up the codebase, and making changes intended to help us move faster in the future and keep the project sustainable.

📦 Freight & Promotion Enrichment

Did you know container images can be annotated with standard or custom annotations at build time?

Beginning with this release, Kargo is able to collect any annotations associated with a container image and include those details in Freight -- and you can easily access them within your promotion processes using expressions.

Similarly, thanks to the efforts of first-time community contributor @​keithfz, metadata about the actor who triggered a Promotion is also now available within your promotion processes via expressions.

🔬 AnalysisRun Logs

Kargo has long supported post-promotion verification using Argo Rollouts AnalysisTemplates / AnalysisRuns, which were specifically designed for reuse in contexts such as this.

Among the many types of metrics that can be collected by an AnalysisRun, job metrics stand out as being especially useful because they're implemented as Kubernetes Jobs, which gives Kargo users the flexibility to define any arbitrary tests they'd like to run against a Stage by simply providing an appropriate Job spec.

One long-standing frustration with job metrics, however, has been the inability to access logs from a Job's underlying Pod(s) via the Kargo UI. This has been a tough nut to crack. Sometimes, perhaps even often, multiple Kargo controllers are situated in different clusters and all sync to a common Kargo control plane in another cluster. Such a topology raises the specific challenge of making logs from many remote clusters available to the Kargo API server. This difficulty notwithstanding, simply ensuring that relevant logs remain available for a reasonable period after the Pod they came from has been deleted is a challenge in its own right.

If we were to ask ten different Kargo users how they approach logging, we probably would get ten different responses, so the Kargo team has avoided getting into the business of supporting many different logging stacks. (We'd rather remain focused on promotions!) Ultimately, we settled on a "lowest common denominator" approach that we think most users will find acceptable.

At install time, Kargo operators may now optionally define a URL template and map of HTTP headers using the api.rollouts.logs.urlTemplate and api.rollouts.logs.httpHeaders settings, respectively. With these defined, the Kargo API server is able to construct a URL for any Job metric's logs, and as long as they are accessible with an HTTP GET request, can stream them to the UI.

This approach does leave it as an exercise for Kargo administrators to ship and store these logs as they choose, and anything is fair game as long as it can meet the low bar of being accessible via an HTTP GET request.

Those using Kargo through the Akuity Platform should note that forwarding and storage of logs from such Jobs will seamlessly be handled for you.

More information is available on this topic in the documentation.

Other Miscellaneous Improvements

The Kargo UI has been the recipient of a numerous small bug fixes and one major improvement -- PromotionTask and ClusterPromotionTask resources can now be managed through the UI.

In the CLI, re-logging in to a Kargo API server when your token (and refresh token, if applicable) have expired is now considerably easier, requiring only kargo login, with all other arguments and flags inherited from the previous login.

🙏 New Contributors

In addition to @​keithfz, mentioned earlier, we'd also like to thank @​zeraye for his first contribution to Kargo.

For a more complete list of everthing accomplished in this release, please refer to the Full Changelog.

v1.3.4

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.3.3...v1.3.4

v1.3.3

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.3.2...v1.3.3

v1.3.2

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.3.1...v1.3.2

v1.3.1

Compare Source

What's Changed

Full Changelog: https://github.com/akuity/kargo/compare/v1.3.0...v1.3.1

v1.3.0

Compare Source

⚠️ Breaking Changes

As announced in our v1.1.0 release notes, several deprecated features from before we introduced support for Expression Language have been removed in this release.

To discover the new way of providing the configuration for these steps, please refer to the updated documentation examples for each step linked above.

⚠️ New Deprecations

Consistent with the changes noted above, the messageFromSteps field of the git-commit promotion step is newly deprecated in favor of using the message field with expressions instead.

messageFromSteps is scheduled for removal in the v1.5.0 release.

✨ New Features

🔀 Conditional Step Execution

Promotion steps now allow the definition of an if expression that evaluates to a boolean value. When this expression evaluates to false, the step is skipped and the next step in the sequence is executed.

apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
  name: test
  namespace: kargo-demo
spec:

### ...
  promotionTemplate:
    spec:
      steps:
      - uses: fake-step
        if: ${{ outputs.step1.someOutput == 'value' }}

While the current use cases for this within Promotion templates may seem limited, it does allow you to conditionally execute a task step based on provided task variables in PromotionTasks.

In a future release, Kargo will be adding support for improved failure and error handling, which will supercharge this feature based on the outcome of previous steps. Follow this issue for more information and updates.

🎛️ Control of Semantics for Freight Requests

Previously, any requested Freight for a Stage was automatically available to it as soon as one of the listed upstream Stages had successfully verified it. Starting with this release, and thanks to the efforts of @​aidan-canva, it is now possible to define an "availability strategy" that requires it to have been verified in all upstream Stages.

apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
   name: uat
   namespace: kargo-demo
spec:
  requestedFreight:
  - origin:
      kind: Warehouse
      name: my-warehouse
    sources:
      stages:
      - test
      - uat
    availabilityStrategy: All

Refer to the updated documentation for more information.

🛡️ Stage Verification Improvements
Expression Language in Arguments

The values specified in args do now support expressions (including functions) to dynamically set values based on the context of the Freight being verified.

For example, the following defines an argument commit with a value set to the commit hash that is being verified using the commitFrom expression function:

apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
  name: test
  namespace: kargo-demo
spec:

### ...
  verification:
    analysisTemplates:
      - name: kargo-demo
    args:
      - name: commit
        value: ${{ commitFrom("https://github.com/example/repo.git").ID }}
Support for ClusterAnalysisTemplates

It is now allowed to reference a ClusterAnalysisTemplate within the verification configuration of a Stage. This enables you as a Kargo operator to define verification checks once and use them across multiple Projects:

apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
  name: dev
  namespace: guestbook
spec:

### ...
  verification:
    analysisTemplates:
    - name: integration-test
      kind: ClusterAnalysisTemplate

Additionally, the ClusterAnalysisTemplates can now be managed through the Kargo UI. Thanks to @​BenHesketh21 for this contribution!

🪜 New and Updated Promotion Steps
🖥️ UI Improvements
  • Scaling issues in the Stage pipeline view have been addressed.
  • As noted in another section, ClusterAnalysisTemplates can now be managed through the UI.
🛠️ Other Notable Changes
  • You can now opt-in to allow credential lookups for HTTP URLs, refer to controller.allowCredentialsOverHTTP in the chart documentation for more information.
  • "Superstar" (i.e. **) glob patterns are now allowed in the include and exclude paths of a Warehouse's Git subscription, making it easier to include or exclude all files and/or directories in nested paths.
  • The Healthy Condition of a Stage will now be Unknown instead of False when the last Promotion failed.
  • Long Stage names will no longer result in AnalysisRun creation failures. (Thanks again @​aidan-canva!)

🙏 New Contributors

Kargo would be nothing without its users. An extra special thank you goes out to community members who made their first contribution to Kargo in this release:

Full Changelog: https://github.com/akuity/kargo/compare/v1.2.3...v1.3.0

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻️ Rebasing: Whenever MR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

  • If you want to rebase/retry this MR, check this box

This MR has been generated by Renovate Bot.

Merge request reports