v1.4.0
🆕 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.