github akuity/kargo v0.2.0

latest releases: v1.0.3, v1.0.2, v1.0.1...
12 months ago

What's Changed

First-Class Freight

Anyone who has been following what we've been doing already knows that "freight" -- a set of references to one or more versioned artifacts -- is an important concept in Kargo. Important as it is, it was nevertheless not represented as its own top-level resource type in Kargo v0.1.0. Freight existed only within the status of various Stage resources. This made it onerous and inefficient for Stage resources, when reconciled, to locate available freight (i.e. other states to which they could be transitioned).

In v0.2.0, we've promoted (pardon the pun) freight to a first-class concept represented by a new custom resource type -- Freight. This small architectural pivot makes it much easier to get a piece of freight, list freight, or query for freight available to a given stage (i.e. freight that has qualified in an upstream stage). The CLI has, of course, evolved along with this change, and it is now possible to get and list Freight.

Warehouses

In Kargo v0.1.0, with freight being the more nebulous concept that it was, production of new freight was tightly-coupled to stages with direct subscriptions to Git, container image, and/or Helm chart repositories.

With freight now having becoming a first-class concept with its own resource type, Kargo v0.2.0 has decoupled the production of new freight from the stages by introducing a warehouse concept, which is also represented by its own custom resource type -- Warehouse.

Warehouse resources now encapsulate subscriptions to one or more Git, container image, and/or Helm chart repositories. Those repositories are polled each time a Warehouse resource is reconciled, at times resulting in the production of new Freight resources. Stages that may previously have subscribed directly to various repositories subscribe indirectly now by subscribing to a warehouse instead.

The CLI and UI have, of course, evolved around this new concept as well. It is possible to use either to "refresh" a warehouse, thereby forcing the repositories to which it subscribes to be polled on-demand.

Most importantly, we believe the warehouse concept introduces a logical place to introduce more fine-grained control over repository subscriptions and the conditions under which new freight is produced as we begin work on v0.3.0.

Bookkeeper Rebranded as Kargo Render

Many Kargo users may not have known about Bookkeeper. Bookkeeper is Kargo's little brother and integrates very well with Kargo. In short, Bookkeeper makes short work of rendering stage-specific configuration in a GitOps repository into plain YAML manifests that it stores in stage-specific branches. Under the hood, it uses your choice of Kustomize or Helm and configuration that lives in the GitOps repository, right alongside the Kustomize overlays or Helm charts on which it operates.

We feel so strongly that Kargo works best when used with Bookkeeper that we've now rebranded Bookkeeper as Kargo Render.

Visit https://kargo-render.akuity.io to learn more!

Other Notable Changes

  • Admin tokens now have a longer default TTL.
  • Promotions are reconciled faster.
  • Reduced (go mod) dependency on Argo CD and GitOps Engine -- part of an overall effort to eliminate those dependencies entirely so we can upgrade Kubernetes freely as needed.
  • Numerous:
    • Small enhancements
    • Documentation improvements
    • Process improvements

New Contributors

We would also like to thank the following first-time community contributors! Their interest in the project and their efforts demonstrate that what we're aspiring to is bigger than Akuity, and that Kargo is out to solve real pain points that are felt throughout the entire GitOps community!

Full Changelog: v0.1.0...v0.2.0

Don't miss a new kargo release

NewReleases is sending notifications on new releases.