Releases: akuity/kargo
v0.8.1
fix(ui): update colors hook (#2347) Signed-off-by: Remington Breeze <[email protected]>
v0.8.1-rc.1
chore(backport release-0.8): fix(ui): stop relying on deprecated fiel… …d in images table (#2345) Co-authored-by: Remington Breeze <[email protected]>
v0.8.0
💥 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-demoNow 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: trueSimilarly, a StageSpec that may previously have subscribed to some upstream Stages, like so:
spec:
subscriptions:
upstreamStages:
- name: test
- name: qaNow 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
- qaFortunately, 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
Contributors
Assets 10
v0.8.0-rc.2
feat: add v0.7.x --> v0.8.x upgrade logic (#2309) Signed-off-by: Hidde Beydals <[email protected]> Signed-off-by: Kent Rancourt <[email protected]> Co-authored-by: Kent Rancourt <[email protected]>
v0.8.0-rc.1
feat(controller): irsa support (#2235) Signed-off-by: Blake Pettersson <[email protected]> Signed-off-by: Kent Rancourt <[email protected]> Co-authored-by: Kent Rancourt <[email protected]>
v0.7.1
fix(promo): notice changes to Argo CD source updates (#2157) Signed-off-by: Hidde Beydals <[email protected]>
v0.7.0
💥 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
Secretat 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:
-
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.
-
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:
Thank you for helping to make Kargo better!
Full Changelog: v0.6.0...v0.7.0
Contributors
Assets 10
v0.7.0-rc.2
chore(backport release-0.7): feat(ui): ability to delete freight (#2111) Co-authored-by: Remington Breeze <[email protected]> Co-authored-by: Kent Rancourt <[email protected]>
v0.7.0-rc.1
fix: refresh promotions using api server's own internal client (#2102) Signed-off-by: Kent Rancourt <[email protected]>
v0.6.0
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.
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
Projectsettings andAnalysisTemplateresources 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 getcommands now support a--no-headersflag, which will avoid printing the column headers when provided.kargo promotecan now wait for aPromotionto 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
googleconnector 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:
