Update dependency akuity/kargo to v0.9.2

[renovate]

This PR contains the following updates:

Package	Update	Change
akuity/kargo	minor	v0.2.0 -> v0.9.2

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

akuity/kargo (akuity/kargo)

v0.9.2

Compare Source

v0.9.1

Compare Source

v0.9.0

Compare Source

💥 Kargo v0.9.0 is here!

🪜 Promotion Steps

This release executes a highly anticipated pivot.

When we first introduced Kargo to the world, its "promotion mechanisms" -- the processes by which Stages are transitioned from one state to another -- were highly opinionated, reflecting our team's own experiences and sense of what practices had served us well up to that point. We've listened intently to feedback from users with differing experience and opinions. Up to a point, we attempted to add "switches and dials" to the existing promotion mechanisms to improve their flexibility, but ultimately found that approach to be unsustainable and also unlikely to ever achieve the degree of flexibility that the maintainers and the community mutually desired.

Around the time of the v0.8.0 release, we decided that a primary focus of the v0.9.0 release would be a pivot toward a much more flexible system for describing promotion processes. Today, we're excited to release the culmination of that effort. Promotion steps represent the new, basic building blocks of more complex promotion processes which users can now more fully customize to suit their specific needs. With them, promotion processes can be composed of discrete actions such as:

• Clone a repository
• Render manifests using helm template or kustomize build
• Commit and push changes to a repository
• Create a pull request
• Sync an Argo CD Application
• And much more

We believe users will find promotion steps to be reminiscent of GitHub Actions, and in fact, we think of this feature as being to CD what GitHub Actions is to CI.

As excited as we are to introduce this feature, we also believe we've only begun to scratch the surface of what this will enable over the longer term:

• We know this shift means more verbose configuration. Over the coming releases, we intend to create "higher-order" steps composed of multiple lower-level steps to reduce the configuration required for common promotion processes. These will differ from legacy promotion mechanisms, which were monolithic and rigid. By contrast, higher-order steps will afford users the flexibility to "drop down" to lower-level steps when higher-order steps do not meet their needs.

• We have long seen the potential for extending Kargo via a plugin system. With promotion steps, we believe we've built a solid foundation upon which to finally integrate custom and third-party functionality into user-defined promotion processes. Over the coming releases, you can expect to see the maintainers doing more work to pave the way for this -- first by isolating promotion processes to their own containers, then later publishing a formal specification for how custom or third-party promotion steps can be implemented and installed. This capability will form the cornerstone of other future functionality, such as notifications.

• Over the coming releases, maintainers also expect to introduce support for a basic expression language to improve the ease with which promotion steps can reference attributes of a the Promotion, the Freight being promoted, the Stage being promoted to, credentials, the output of previous steps, and more.

Finally, this pivot does mean the deprecation of the legacy promotion mechanisms. The v0.9.x series of releases will continue to support those legacy mechanisms, but users should expect them to be removed in the releases > v0.9.x. The community should expect no further investment in improving those legacy mechanisms.

To learn more about promotion steps, please refer to the updated concepts doc and to the new promotion steps reference doc. Our quickstart has also been updated to showcase the new promotion steps feature.

‼️ Breaking Changes

We continue to strive toward minimizing breaking changes. There are just a few to make note of in this release:

• As previously mentioned, the legacy promotion mechanisms are now deprecated and will be removed in releases > v0.9.x. Automated migration from the legacy promotion mechanisms to promotion steps was not feasible, which is why we elected to continue supporting the legacy promotion mechanisms in the v0.9.x series of releases.

• The annotation keys rbac.kargo.akuity.io/sub, rbac.kargo.akuity.io/email, and rbac.kargo.akuity.io/groups used for mapping SSO users to Kubernetes ServiceAccounts have changed to rbac.kargo.akuity.io/claim.sub, rbac.kargo.akuity.io/claim.email, and rbac.kargo.akuity.io/claim.groups, respectively. Kargo will automatically migrate the old annotation keys to the new ones upon upgrade, but if you are gitops'ing your Kargo configuration, you may also wish to update it manually.

• The kargo.akuity.io/authorized-stage annotation that is applied to Argo CD Application resources to indicate consent to be modified or synced by a given Stage has dropped support for wildcards. Values for this annotation must now be of the form <project name>:<stage name>. If you have been using values of the form <project name>:*, you will need to update your configuration to use the specific Stage name. The technical justifications for this change can be found in https://github.com/akuity/kargo/pull/2617.

🆕 Other Major Features

• With special thanks to @​gnadaban, Kargo is now able to perform comprehensive health checks on Stages that integrate with multi-source Argo CD Applications.

• @​BenHesketh21 has generalized the mapping of SSO users to Kubernetes ServiceAccounts via OIDC claims. While only sub, email, and groups claims were previously supported, any claims supported by your identity provider can now be referenced by these mappings.

• @​lknite collaborated with maintainers to make it significantly easier to customize the CA bundles used by Kargo's API server and controller components.

🆕 UI Improvements

As has been customary, this release is packed with too many UI improvements to list. Here are some highlights:

• Live view of in-progress promotions. See what step is currently running as well as the configuration, outcome, and output of each step.

• Is your Freight timeline getting too crowded? It is now possible to hide Freight older than the oldest still in use or all currently unused Freight.

• The pipeline view now surfaces considerably more information about the status of each Stage.

• Have long pipelines? You can now zoom in to focus on a specific segment or zoom out for a holistic view.

🆕 CLI Improvements

• Settings in your local Kargo CLI configuration will now be retained, instead of being reset, when re-authenticating to the same Kargo server.

• The kargo server command finally fully works! This enables an interesting option that some orgs with a few highly-privileged Kargo users may wish to take advantage of. Instead of centrally hosting a Kargo API server, which usually requires configuring SSO, users who have direct access to the Kargo control plane's underlying cluster can run the API server locally and all operations performed by the API server will be carried out using the user's own cluster credentials (i.e. from ~/.kube/config).

🛡️ Security Improvements

Like to GitOps everything including your Kargo Projects? (Great! We do too!) Now you can optionally disable the API server's access to Project Secrets at install-time as there will be no need for that access when credentials are no longer managed via the Kargo UI or CLI.

🗞️ Project News

With mixed emotions, we bid farewell to maintainer @​rbreeze as he moves on to new opportunities. The project is indebted to him for his extensive contributions, most notably Kargo's tremendous UI. With his departure, our colleague, @​Marvin9 will be stepping up to play a more central role in the project.

This release also welcomes @​fykaa to the ranks of the project maintainers!

💥 GA Imminent

Now for some truly big news!

The v0.9.0 release and our pivot to promotion steps marks a major milestone for the Kargo project. While we will no doubt continue to innovate at the brisk pace that you have come to expect through the introduction of new and experimental features (much like Kubernetes does), the maintainers are now confident that we have implemented the right set of core features. Satisfied with the stability of those features, which we, ourselves, are using in production, we consider Kargo's general availability to be imminent.

Expect our next major release to be v1.0.0!

🙏 New Contributors

Last, but not least, we are grateful to the vibrant community that makes this project possible. We would like to extend a special thank you to community members who have gone above and beyond by making their first contributions to the project in this release:

• @​BasJ93
• @​loafoe
• @​walsm232
• @​lknite
• @​BenHesketh21

Full Changelog: akuity/kargo@v0.8.8...v0.9.0

v0.8.8

Compare Source

v0.8.7

Compare Source

What's Changed

• feat: support kustomize image newName override by @​jessesuen in https://github.com/akuity/kargo/pull/2471

Full Changelog: akuity/kargo@v0.8.6...v0.8.7

v0.8.6

Compare Source

v0.8.5

Compare Source

v0.8.4

Compare Source

v0.8.3

Compare Source

v0.8.2

Compare Source

v0.8.1

Compare Source

v0.8.0

Compare Source

💥  Kargo v0.8.0 is here!

As with all our minor releases, v0.8.0 ushers in numerous improvements and bug fixes, but also has a heavy focus on one major new feature: Multi-Pipelines.

Multi-Pipelines

"Pipeline" has never been a well-defined term in Kargo. It's been intuitively and widely understood to represent the path that Freight takes from a Warehouse, through a DAG of Stages, and into production.

Until now, only one such pipeline could be thought of as passing through each Stage. Although a Stage could subscribe to multiple upstream Stages, this only ever expressed that Freight should be considered available for promotion to that Stage after being verified in any one of its upstream Stages. Ultimately, Stages (or, more accurately, their underlying environments) were still constrained to hosting only one piece of Freight at a time. Some users with advanced use cases have found this limiting and have long been asking for Stages to be able to host multiple pieces of Freight (of different types) at once.

Why would someone want this? In general terms it is the product of a desire to advance different artifacts through the same Stages in parallel, and likely at different cadences. Examples:

• CI may publish many new Docker images in a day, and a user may typically wish to advance these all the way through to production rather quickly. By contrast, they may wish for new manifests to advance more slowly and "soak" for some time in each Stage.

• An application may be composed of many microservices that can be delivered in parallel. Kargo has handled this well for some time now if users manage a separate set of Stages for each microservice, but this can be cumbersome and fails to visually convey that the microservices are components of a larger whole.

In short, Freight, as meta-artifacts, have been fantastic for delivering sets of related artifacts as a unit, but sometimes users need to deliver related artifacts (or sets of artifacts) independently of one another.

Kargo v0.8.0 introduces the ability for Stages to host multiple pieces of Freight, of different types, simultaneously. Stages can now be thought of as possessing multiple "slots" for different types of Freight, with multiple pipelines passing through each Stage, dropping off different types of Freight to fill those slots -- and potentially doing so at different cadences.

Breaking Changes

With Stages gaining the ability to host multiple pieces of Freight simultaneously, as discussed above, there are obvious implications for the spec and status of Stage resources. Where Stages could previously subscribe to a Warehouse, or to one or more upstream Stages, permitting Stages to host multiple pieces of Freight simultaneously necessitates that Stages can reference Warehouses and/or Stages as sources for multiple types of Freight. Similarly, while the status of a Stage previously tracked which one piece of Freight's artifacts were deployed to the underlying environment, it now needs to track this information for multiple pieces of Freight of different types.

These changes have forced Kargo to incur some breaking changes -- which the team is avoided whenever all but unavoidable.

A StageSpec that may previously have subscribed to a Warehouse, like so:

spec:
  subscriptions:
    warehouse: kargo-demo

Now expresses a "request" for a particular type of Freight (as described why where it originated from) and indicates a willingness to accept it directly from that origin (its Warehouse):

spec:
  requestedFreight:
  - origin:
       kind: Warehouse
       name: kargo-demo
  sources:
    direct: true

Similarly, a StageSpec that may previously have subscribed to some upstream Stages, like so:

spec:
  subscriptions:
    upstreamStages:
    - name: test
    - name: qa

Now expresses a "request" for a particular type of Freight and indicates a willingness to accept it from certain upstream Stages (but not directly from its origin, in this case):

spec:
  requestedFreight:
  - origin:
  	kind: Warehouse
  	name: kargo-demo
    sources:
      stages:
      - test
      - qa

Fortunately, the team has (as we've done with previous releases) been able to automate the migration process from v0.7.x to v0.8.0. There is no automatic migration from versions prior to v0.7.0.

Although this migration process will keep things running smoothly in the near term, it is suggested that, especially if you GitOps your Kargo Projects, that you update your StageSpecs so that your GitOps agent (e.g. Argo CD) won't find itself perpetually at odds with Kargo's automated upgrade process. v0.9.0 can also be expected to remove all fields deprecated in the course of this change, creating further impetus to update your StageSpecs.

Credentials

Kargo v0.8.0 introduces a variety of new integrations for obtaining credentials for accessing Git and OCI repositories.

• Building off of v0.7.0's support for using EKS Pod Identity to access image
  repositories hosted in ECR:
  • Kargo now supports using IRSA as well.
  • EKS Pod Identity and IRSA now work for accessing chart repositories hosted in ECR.
  • If Kargo is unable to assume a Project-specific IAM role, it will fall back on directly using the IAM role associated with the Kargo controller. This can relieve the overhead of managing many Project-specific IAM roles for users without strict tenant isolation requirements.
• Improved and well-validated support for accessing Git repositories hosted in GitHub Enterprise and in self-hosted GitLab instances.

UI

As usual, there are too many UI improvements to list, but here are some highlights:

• Projects view is now paginated and searchable.
• Sidebar navigation now contains links to documentation and CLI binaries.
• "Freightline" has been renamed to "Freight Timeline" in an attempt to emphasize that it is simply a stream of Freight arranged chronologically.
• Freight Timeline can now be filtered by Warehouse. Freight older than the oldest still in use can be hidden to improve UI performance.
• The image history table can be hidden.

Miscellaneous Improvements

• When evaluating Stage health:
  • Associated Argo CD Applications in a "Suspended" state now cause the Stage to be counted as "Progressing."
  • A grace period is now observed after an associated Argo CD Application first becomes "Healthy" after a promotion. This is to reduce the impact of Argo CD Applications that falsely report that they are healthy in the moments immediately following a sync.
• Improved Freight-comparison logic to be less dependent on deterministically calculated Freight ID, as the algorithm for calculating this ID has sometimes changed from one release to the next.

Where We Go From Here

It's a good time to start preparing our community for the breaking changes we anticipate in v0.9.0.

The extremely varied and complex nature of the use cases we are seeing among Kargo users has made it clear that our promotion mechanisms require fewer opinions and more flexibility. To this end, we are planning to replace our tree of opinionated promotion mechanisms with the ability to execute an ordered list of promotion directives. These directives will be more granular, thereby permitting users to describe more complex promotion processes. Perhaps more importantly, we anticipate this pivot paving the way for user-defined or third-party promotion directives, upon which alternative and more sophisticated storage, configuration management, notification, and approval capabilities will be built.

As usual, you can expect the Kargo team to make every effort to automate the upgrade process such that any breaking changes incurred in v0.9.0 will pose minimal disruption to your Kargo Projects.

New Community Contributors

Last, but certainly not least, Kargo would be nothing without its community, so we'd like to recognize @​anubhav06 for their first contribution, which is included in this release. Thank you for helping to make Kargo better!

Full Changelog: v0.7.1...v0.8.0

v0.7.1

Compare Source

v0.7.0

Compare Source

💥  Akuity and our valued collaborators are excited to unveil Kargo v0.7.0!

As with the last several releases, this one is so jam-packed with changes and features that we're going to focus here on just a few highlights and invite you to consult the full changelog if you want to learn more.

Upgrade Path

If you are upgrading from v0.6.0, you're all set.

There is no upgrade path from versions prior to v0.6.0.

ECR and Google Artifact Registry Support

🆕  New Features

The community spoke and we listened.

Things weren't going so well for users with Warehouses subscribed to ECR and Google Artifact Registry (or GCR) repositories.

ECR offers no option at all for accessing repositories using long-term credentials, which was making it quite impossible to furnish Kargo with a username and password/token in the form of a Kubernetes Secret.

While Google Artifact Registry does offer an option for accessing repositories with long-term credentials, that option is not recommended by Google -- or by Kargo.

With all of this in mind, we've added new options for authenticating to these registries:

• Provide an AWS access key ID + secret access key or a GCP service account key and Kargo will use them to obtain short-lived tokens.

  These are "lowest common denominator" options that one might settle for if using ECR or Google Container Registry but running Kargo outside of EKS or GKE, respectively.

• Support for obtaining short-lived tokens without involving any Secret at all by leveraging:

  • EKS Pod Identity

  • GKE Workload Identity Federation

You can read more about these new options in our documentation.

Improved Artifact Discovery and Manual Freight Assembly

🆕  New Features

Until now, Warehouses have selected the latest artifact that matches each subscription's criteria and constraints, but this has sometimes led to undesirable behaviors:

1. If two versions of an artifact were pushed in rapid succession, a subscribed Warehouse might miss the older of the two and only create Freight using the newer one -- which is a problem if you had any interest in progressing the older of the two through your pipeline.

2. If related changes were pushed to two repositories (e.g. a new image version and its related configuration) a Warehouse subscribed to both might have found the latest artifacts and created Freight from them between the two pushes, resulting in an invalid combination, such as a new image without the new configuration that it depends on.

A few new features offer solutions to such problems:

• Warehouses now discovers many recent versions of each artifact that meet each subscription's criteria and constraints.
• Warehouses can be configured to not create Freight automatically when new artifacts are found.
• It is now possible to manually select a combination of artifacts discovered by a Warehouse to build your own Freight.
• How frequently Warehouses discover new artifacts can be configured.
• Uninterested in some piece of Freight? You can now delete it.

Assorted UI Improvements

🆕  New Features

Just the highlights:

• As with Stages and Freight, you can now open an expanded/details view of a Warehouse by clickon on it.
• Click a filter button on a Warehouse or select a Warehouse from a dropdown to apply a filter to the Freightline.
• Abort and retry verifications from the UI.
• New, lighter theme.

New Community Contributors

Last, but certainly not least, Kargo would be nothing without its community, so we'd like to acknowledge community members whose first contributions are included in this release:

• @​wmiller112
• @​akolacz

Thank you for helping to make Kargo better!

Full Changelog: v0.6.0...v0.7.0

v0.6.0

Compare Source

What's Changed

The Kargo team is thrilled to announce the release of v0.6.0, packed with stability improvements, enhancements, and new features. While the list of improvements and additions is extensive, we have highlighted some features you can look forward to exploring.

If you are looking for a more complete list, please do consult the full changelog

Notes on Upgrading

There is a single breaking change: the "well-known" kargo-secret-manager ClusterRole has been renamed to kargo-project-admin. However, this release includes a built-in upgrade reconciler to ensure a seamless upgrade process by automatically changing any project-level bindings referencing the old name to reference the new one.

⚠️ Please note that if you are upgrading from a version older than v0.5.0, you first need to upgrade to v0.5.x before upgrading to v0.6.0. This is due to breaking changes introduced in v0.5.0, for which no upgrade aid exists in this release.

Role Management

Kargo will now create two roles in every Project: kargo-admin and kargo-viewer.

The Kargo UI and CLI further allow creating and managing additional roles to provide scoped access to Kargo resources in a Project, which can be mapped to OIDC emails, subjects, and groups.

Warehouse Filters

In v0.5.0, Warehouse subscription filters using regular expressions were introduced. Making it possible to, for instance, subscribe to a monorepo, but trigger the production of new Freight only when changes to relevant paths are detected.

In this release, this feature has been further enhanced to support glob patterns (using a glob: prefix) and exact paths to files or directories. Additionally, the filters now apply to all commit selection strategies (and not just NewestFromBranch).

For more detailed information, please take a look at the Kargo documentation.

Kubernetes Events

Kargo will now emit Kubernetes Events for noteworthy changes. For example, when a new Promotion is created or the verification of Freight in a Stage succeeded. These events can also be viewed in the newly introduced events tab in the Project dashboard of the Kargo UI.

GitLab Merge Requests

In v0.3.0, support for opening a GitHub pull request was added to Git-based promotion mechanisms. With the help of @​PhilippParis, this has now been expanded to support GitLab merge requests.

UI Improvements

• Project settings and AnalysisTemplate resources can now be managed through the UI.
• Variety of bug fixes and other stability improvements.

Other Notable Features

• Credentials can now include descriptions, which are displayed in the UI for informational purposes. We plan to expand this feature to more Kargo resource types in the future.
• kargo get commands now support a --no-headers flag, which will avoid printing the column headers when provided.
• kargo promote can now wait for a Promotion to finish using --wait.
• Kargo can now be configured (via the chart configuration) to sign commits with a GPG key.
• Arbitrary volumes can be mounted to the optional Dex server (via the chart configuration) to support more complex connector configurations. This can for example be useful to configure Dex's google connector to get additional Google Groups information from your users, allowing you to assign permissions to members of a Google Group.

New Contributors

Last, but certainly not least, Kargo would be nothing without its community, so we'd like to take a moment to thank community members whose first contributions to the project are included in this release:

• @​blakepettersson
• @​ed-boykin
• @​PhilippParis
• @​vavdoshka
• @​zkhvan

v0.5.2

Compare Source

v0.5.1

Compare Source

v0.5.0

Compare Source

💥  The Kargo v0.5.0 release is here and wow! -- it's a big one!

So much has gone into this release that it's been really difficult narrowing the release notes down to just a few highlights. Here are some of the most noteworthy features and fixes. If you're looking for a more complete list, please do consult the full changelog.

Upgrade Path

If you read only one section of the release notes, let this be this one.

If you are upgrading from v0.4.x to v0.5.0, you should run this script first to ensure a smooth upgrade of Kargo's CRDs. If you do not run the script, you will likely see errors in your controllers, but it will not be too late to run it and re-attempt the upgrade.

Future CRD upgrades will be less onerous for reasons discussed in the Chart Improvements section.

All other breaking changes should be well-accounted for by specialized upgrade reconcilers that are included in this release, but are not present in our main branch. (i.e. They will be gone in v0.6.0.) They will make small changes to:

• Status of existing Stage resources
• Ownership references on existing Freight resources
• Labels and format of credentials (specially-formatted Secret resources)

If you manage your Kargo projects using Argo CD, you may find that the last change (to credentials) brings your projects out of sync with your Applications. Should that occur, please consult the Managing Credentials section of the Kargo documentation for details about the new format.

There is no upgrade path from versions prior to v0.4.0.

All New CLI

⚠️  Breaking Change

The CLI has been virtually rewritten from the ground up. Up until now it wasn't an area of the project that had received the attention it deserved and we knew its UX needed quite a bit of work. All that has changed with this release!

The updated CLI should feel more intuitive across the board, behavior and help text should be more consistent from one command to the next, and we've added quite a bit of new functionality as well. 🆕  Especially notable is that credentials can now be managed and verification processes re-run or even aborted via CLI.

If you upgrade Kargo's cluster-side components, you must also upgrade the CLI (if you use it).

New Path Filtering Rules

🆕  New Feature

A frequently requested feature has been the ability to narrow a Warehouse resource's subscriptions to Git repositories to include or exclude changes to certain paths. This feature has now been implemented and makes it possible to, for instance, subscribe to a monorepo, but trigger the production of new Freight only when changes to relevant paths are detected.

The Kargo team wishes to specifically thank @​maksimstankevic for their extensive work on this feature. To date, this is the largest feature contributed by a non-maintainer and we are very grateful for both the effort and the quality of the work.

Credential Storage

⚠️  Breaking Change

Repository credential storage has been significantly refactored in this release. The strategy previously employed closely emulated Argo CD -- and this included idiosyncrasies that existed in Argo CD for legacy reasons, but could stand to be improved in Kargo. With this change, the capability of "borrowing" credentials from Argo CD has also been completely removed.

The new strategy is considerably more straightforward.

As indicated in the Upgrade Path section, Kargo v0.5.0 will automatically update the format of existing repository credentials. If any difficulties are encountered, please do consult the Managing Credentials section of the Kargo documentation.

Chart Improvements

• 🔧  Kargo CRDs can now be upgraded via the chart. This was not possible before because we took advantage of Helm's support for a dedicated crds/ directory. A limitation of that approach is that upgrades to a Kargo installation did not upgrade the CRDs. (Read more about this here.) This limitation has been overcome by moving the CRDs into the chart's templates/ directory instead.

  One consequence of this change is that if you plan to upgrade to Kargo v0.5.0 from an older version, you will first need execute a script that adopts non-Helm-managed Kargo CRDs into your existing Kargo release.

• 🆕  Installation of the Kargo chart now includes kargo-admin and kargo-viewer ServiceAccounts, which can be mapped to specific API users via subject, email, or group OpenID Connect claims. This is useful for organizations that may wish to:

  • Grant broad (all Projects) read-only access to all authenticated users.

  • Grant broad (all Projects) administrative access to a small subset of specific users or users belonging to a specific group.

  • Install Kargo with the built-in admin user disabled (recommended).

  Additionally, the Kargo management controller will automatically expand and contract the permissions of the kargo-admin ServiceAccount to include credential-management (Secret-management) permissions as Project resources are created and deleted. This dynamic expansion and contraction of permission to access Secrets in individual namespaces prevents the kargo-admin ServiceAccount from requiring cluster-wide access to Secret resources.

Improved Garbage Collection

Garbage collection has been improved in a number of ways:

• 🆕  Argo Rollouts AnalysisRun resources used to verify Stage/Freight pairs are now owned by the relevant Freight. The result is that as old and unused Freight is itself garbage collected, so too are the associated AnalysisRun resources.

• 🆕  Freight is now being garbage collected -- it wasn't before. This is quite important to overall cluster health since Freight resources are quite likely to become extremely numerous over time. Of course, we never wish to garbage collect Freight that is still in use. By default, the garbage collector will, Project by Project, Warehouse by Warehouse, delete only Freight that are both more than 20 generations older than the oldest Freight still in use and also more than two weeks old.

• 🔧  Promotion resources are now being garbage collected more conservatively. Previously, the garbage collector would, Project by Project, delete the very oldest Promotion resources. This proved to be a mistake, as it is possible that some very old Promotions are still relevant, while newer ones are not. Such a situation can arise, for instance, if the last Promotion to production were in the distant past, while many Promotions to Stages upstream from production have occurred since. The improved garbage collection of Promotion resources now takes this into account by working Project by Project, and Stage by Stage, deleting only Promotion resources that are both more than 20 generations older than the oldest Promotion in a non-terminal phase and also more than two weeks old.

UI Improvements

• 🆕  The following can now be created and managed via the UI:

  • Projects
  • Warehouses
  • Credentials (specially-formatted Secrets)
  • AnalysisTemplates (used for verifications)

• 🔧  Warehouses with no subscribers are now displayed correctly.

• 🔧  Warehouses with multiple Stages subscribed directly to them are now displayed correctly.

• 🔧  Numerous layour tweaks

New Maintainer

We're pleased to have had @​hiddeco join the team at Akuity as a new Kargo maintainer. His efforts were instrumental in making v0.5.0 our most feature-rich and stable release to date. We're excited that his addition to the team will both accelerate the pace of development and further improve the overall quality of the project!

New Community Contributors

Last, but certainly not least, Kargo would be nothing without its community, so we'd like to acknowledge community members whose first contributions are included in this release:

• @​sennerholm
• @​MPritsch
• @​sthomson-wyn
• @​ftmiro
• @​michaelasper
• @​Exchizz
• @​jacobnguyenn

Thank you all for your contributions!

Full Changelog: v0.4.5...v0.5.0

v0.4.5

Compare Source

What's Changed

• fix(cli): restore ability to read manifests from stdin -- 0.4 edition by @​krancour in https://github.com/akuity/kargo/pull/1716

Full Changelog: akuity/kargo@v0.4.4...v0.4.5

v0.4.4

Compare Source

What's Changed

• chore(chart): be more careful about undefined values -- 0.4.x edition by @​krancour in https://github.com/akuity/kargo/pull/1603

Full Changelog: akuity/kargo@v0.4.3...v0.4.4

v0.4.3

Compare Source

What's Changed

• fix(chart): warnings in chart install/upgrade by @​krancour in https://github.com/akuity/kargo/pull/1558

Full Changelog: akuity/kargo@v0.4.2...v0.4.3

v0.4.2

Compare Source

What's Changed

• fix(cli): don't involve kubeconfig in reading bytes from files by @​krancour in https://github.com/akuity/kargo/pull/1528

Full Changelog: akuity/kargo@v0.4.1...v0.4.2

v0.4.1

Compare Source

What's Changed

• fix(crds): stage validation issue with kargo render promo mechs by @​krancour in https://github.com/akuity/kargo/pull/1519

Full Changelog: akuity/kargo@v0.4.0...v0.4.1

v0.4.0

Compare Source

The Kargo team is proud to bring you v0.4.0!

⚠️  With Kargo still in its early stages, and the team still learning what works and what doesn't, this release has some small breaking changes. The notes that follow will call special attention to them.

What's New

The Project CRD

🆕  New Feature

⚠️  Breaking Change

Kargo projects are not a new concept. They've been the fundamental unit of workspace organization and tenancy since before Kargo's first release. Prior to v0.4.0, projects were implemented as mere Kubernetes namespaces having a special project label.

We have long been striving to improve th experience of bootstrapping new projects, and to that end, v0.4.0 introduces the Project CRD. This new resource type reconciles to a specially labeled Kubernetes namespace.

Why do it this way? There are some specific advantages:

• Users can be granted permissions to create Project resources without granting them the ability to directly create non-project Kubernetes namespaces.

• Additional project-level configuration can be added to a Project resource. At present, this only includes promotion policies, but will include more in future releases.

  ⚠️  Complementing this change, the PromotionPolicy resource type has been removed.

• In future releases, we intend to implement additional project-bootstrapping logic as part of Project reconciliation. This is likely to include the creation of project-scoped ServiceAccounts, Roles, and RoleBindings.

• The Project resource type will provide a convenient place to aggregate project-level statuses and statistics in future releases.

A few other notes on this change:

• Project resources own the underlying namespace. Deleting a Project will delete the namespace and everything in it. The Kargo controller also provides the inverse functionality. If you delete the namespace, the owning Project resource will be deleted.

• As a convenience to users coming from older versions, if you already have appropriately labeled "project" namespaces in your cluster, and create a Project resource with the same name, the Project will "adopt" that existing namespace unless it is, for some reason, already has other owner references.

Tag-Based Constraints on Git Repository Subscriptions

🆕  New Feature

Warehouse resources have long been able to specify strategies and tag-based constraints for the selection of container images from image repositories. Kargo v0.4.0 introduces similar, optional, constraints for for the selection of a commit from a Git repository.

Why? Just like you may not want to push every container image you build in CI into your delivery pipeline, you many not want to continuously push every single configuration change into that pipeline either. If that's the case, you can now take control by tagging your commits appropriately when you are ready to move them into the pipeline.

The following example Warehouse resource will only produce new Freight resources when it finds a new tag of the form release-\d{4}-\d{2}-\d{2} in the repository:

apiVersion: kargo.akuity.io/v1alpha1
kind: Warehouse
metadata:
  name: my-warehouse
spec:
  subscriptions:
  - git:
      repoURL: https://github.com/some/repo.git
      commitSelectionStrategy: Lexical
      allowTags: release-\d{4}-\d{2}-\d{2}

This is but one example. All the new options are documented here.

Image Selection Strategies

⚠️  Breaking Change

Prior to v0.4.0, Kargo Warehouse resources subscribing to container image repositories would specify a "tag selection strategy" in the tagSelectionStrategy field. This field name was a misnomer. Although the available strategies all employ tag-based constraints, they ultimately facilitate the selection of an image.

Beginning in v0.4.0, Warehouse resources subscribing to container image repositories specify an image selection strategy instead.

Before and after this change, the selection strategy defaults to SemVer when left unspecified. This breaking change, therefore, only affects users of the other three strategies: Digest, Lexical, and NewestBuild.

Playing Nicer with Helm

⚠️  Breaking Change

Prior to v0.4.0, Kargo Warehouses subscribed to Helm charts using registryURL and name fields. For reasons too complex to explain briefly, the registryURL field generated a lot of confusion.

Beginning in v0.4.0, Warehouse resources subscribe to Helm chart repositories using a repositoryURL field instead. For classic (HTTP/S) chart repositories the name field is required to qualify the desired chart since such repositories may contain multiple, differently named charts. For OCI repository subscriptions, a repository URL unambiguously points to a single chart, so the name field must remain empty in that case. A validating webhook will enforce these rules and prevent any mistakes.

When using promotion mechanisms that either mutate the targetRevision fields of Argo CD Application sources or ones that mutate the versions of chart dependencies in Chart.yaml files, define the rules for identifying the targets of those changes by simply matching the corresponding fields in the Application sources or chart dependencies exactly. If those values differ slightly from your Warehouse Kargo will figure it out.

Argo CD Credential Borrowing Removed

⚠️  Breaking Change

Prior to v0.4.0, Kubernetes Secret resources containing repository credentials used by Argo CD could be "borrowed" by Kargo projects if specially annotated in a manner indicating consent. This feature was conceived very early in Kargo's development and was an overreaction to the feeling of creating separate but similar credential Secrets for use by each of Argo CD and Kargo.

Any similarities between the credentials used by Argo CD and Kargo are, however, were largely superficial. Digging deeper, one quickly realizes that Argo CD always requires only read-only access to Git or chart repositories, and never requires any access to image repositories. Kargo, on the other hand, frequently requires read/write access to Git repositories and frequently does require (read-only) access to image repositories.

To keep things DRY, one might be tempted to extend permissions to Argo CD that it doesn't require, but in doing so, the principle of least privilege is violated.

To discourage this poor security practice, Kargo v0.4.0 removes the Argo CD credential borrowing feature.

Other, Smaller Changes

• UI:
  • Support for OAuth 2 refresh tokens
  • Support for editing Freight aliases (previously only possible via CLI)
• CLI:
  • apply and delete commands now support Secret resources (for credentials; previously required using kubectl)
  • approve command added for manually approving Freight (previously only possible via UI)
  • dashboard command added to open UI in system default browser
  • logout command added
• Support for Git repositories secured with self-signed certificates
• Miscellaneous bug fixes and performance improvements

New Contributors

Last, but certainly not least, Kargo would be nothing without its community, so
we'd like to take a moment to thank community members whose first contributions
to the project are included in this release:

• @​paulliwog
• @​Juneezee
• @​lrotim
• @​Tchoupinax
• @​Brightside56
• @​snooyen
• @​mfreeman451
• @​maksimstankevic
• @​webstradev

Full Changelog: akuity/kargo@v0.3.2...v0.4.0

v0.3.2

Compare Source

What's Changed

Bug fixes:

• Fix how app sync state impacts Stage health
• Always normalize git urls before comparisons

Full Changelog: akuity/kargo@v0.3.1...v0.3.2

v0.3.1

Compare Source

What's Changed

Bug fixes:

• Fix CLI failures that occur when CLI configuration does not already exist.

Full Changelog: akuity/kargo@v0.3.0...v0.3.1

v0.3.0

Compare Source

The Kargo team is pleased to present a feature-packed v0.3.0 release!

⚠️  Be warned that with Kargo still in its early stages, and the team still learning what works and what doesn't, this release is packed with breaking changes. There is no supported upgrade path to v0.3.0 from previous releases.

What's New

PR-Based Promotions

Git-based promotion mechanisms may now, optionally, open a pull request instead of committing directly to a branch. Such promotions remain in a running state until the pull request is merged or closed. This exciting new capability gives teams the option to utilize code review as an implicit approval process.

This feature is currently only supported for GitHub repositories.

Verifications

After a successful promotion, Stage resources now enter a Verifying phase. Once such a Stage has cleared any applicable health checks, an optional, user-defined verification process is executed.

Some users may be familiar with Argo Rollouts AnalysisTemplate resources (and the AnalysisRun resources that are spawned from them). These were intentionally built to be re-usable in contexts other than Argo Rollouts. Kargo's user-defined verification processes, therefore, take the form of one or more references to AnalysisTemplate resources that reside in the same project/namespace as the Stage resource, which grants those processes all the benefits of this rich and battle-tested feature of Argo Rollouts.

SSO Improvements

Kargo is typically configured to support single-sign-on (SSO) using an external identity provider that implements the OpenID Connect protocol.

Kargo also implements authorization of all user actions using pure Kubernetes RBAC. i.e. Permission to perform various actions on various Kargo resources is therefore granted via RoleBinding resources that associate users or ServiceAccount resources with Role resources.

Because Kargo users log into the Kargo CLI or UI via SSO, their identifies are unknown to Kargo's underlying Kubernetes cluster. This represents an impediment to using Kubernetes RBAC to authorize the actions of such users. Kargo now answers this challenge through a scheme that permits users to be mapped to zero or more Kubernetes ServiceAccount resources.

Please, refer to the documentation for more details.

Freight Improvements

Aliases

If you've tried Kargo before, you may have noticed that each Freight resource's ID is a SHA-1 hash of that Freight resource's contents. Deriving the ID deterministically from the contents provides numerous technical benefits, but working with SHA-1 hashes is, to say the least, cumbersome for human users.

To that end, new Freight resources are now labeled with whimsical, system-generated aliases that are each guaranteed to be unique within the project/namespace. Unlike a Freight resource's ID, its alias is mutable, meaning users may optionally confer meaningful aliases on important pieces of Freight, such as a likely release candidate.

Updating Freight aliases is currently available via the Kargo CLI only. i.e. This feature is not yet present in the UI.

Manual Approvals

One bit of feedback we've heard a lot of is that a stringent requirement that a new piece of Freight traverses an entire delivery pipeline to reach production is too restrictive when the need for hotfix occasionally arises. To that end, Freight resources may now be manually approved for promotion to any Stage, thereby enabling that Freight to bypass deployment and verification in any number of intermediate Stages.

Manual Freight approval is currently available via the Kargo UI only. i.e. This feature is not yet present in the CLI.

Miscellaneous Improvements

• Warehouse resources now perform shallow, single-branch clones of the Git repositories they subscribe to.

• Freight references to container images now include digests as well as tags and digests can even be used in promotion processes in place of tags for a higher degree of determinism.

• Much as with kubectl, Kargo CLI users may now configure a default project/namespace.

• Numerous devx improvements.

• Too many UI improvements and bug fixes to enumerate here!

New Contributors

Last, but certainly not least, Kargo would be nothing without its community, so we'd like to take a moment to thank community members whose first contributions to the project are included in this release:

• @​paulliwog made their first contribution in https://github.com/akuity/kargo/pull/1135
• @​Juneezee made their first contribution in https://github.com/akuity/kargo/pull/1142
• @​lrotim made their first contribution in https://github.com/akuity/kargo/pull/1041
• @​Tchoupinax made their first contribution in https://github.com/akuity/kargo/pull/1223
• @​Brightside56 made their first contribution in https://github.com/akuity/kargo/pull/1288
• @​snooyen made their first contribution in https://github.com/akuity/kargo/pull/1277

Full Changelog: akuity/kargo@v0.2.1...v0.3.0

v0.2.1

Compare Source

What's Changed

Bug fixes:

• Fixed auto-promotions
• Prevented Kargo Render failures from bleeding git repo credentials into logs
• Gave controller permission to patch warehouses
• Fixed broken "promote to subscribers" button (the "truck button") in UI

Full Changelog: akuity/kargo@v0.2.0...v0.2.1

---

Configuration

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

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

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

---

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

---

This PR was generated by Mend Renovate. View the repository job log.