Skip to main content

v1.2.0

🆕 What's New?​

💪 Promotion Tasks​

When support for expressions in promotion steps debuted in Kargo v1.1.0, we had a vision of eventually leveraging that capability to define reusable sequences of steps, where the particulars of each Stage utilizing them in their Promotions could be provided, essentially, as arguments. v1.2.0 makes that vision a reality with the introduction of PromotionTasks (and ClusterPromotionTasks).

We've observed the majority of our users housing their application configurations in monorepos, so with little difficulty, we can imagine such a repository housing configuration for dozens or even hundreds of applications, with each of those configurations also having a number of variations for each of several environments. Among these applications, many are likely to employ the same directory structure and configuration management tools. Prior to Kargo v1.2.0, each and every Stage representing an application/environment pair would have had to individually define a promotion process that would have been remarkably similar from one to the next.

With PromotionTasks, a sequence of common steps can be defined like so:

apiVersion: kargo.akuity.io/v1alpha1
kind: PromotionTask
metadata:
name: standard-process
namespace: guestbook
spec:
vars:
- name: app
- name: imageRepo
steps:
- uses: git-clone
config:
repoURL: https://github.com/example/monorepo.git
checkout:
- path: ./configs
- uses: yaml-update
config:
path: ./configs/${{ vars.app }}/chart/envs/${{ ctx.stage }}/values.yaml
updates:
- key: image.tag
value: ${{ imageFrom(vars.imageRepo).Tag }}
- uses: git-commit
config:
path: ./configs
- uses: git-push
config:
path: ./configs
- uses: argocd-update
config:
apps:
- name: ${{ vars.app }}-${{ ctx.stage }}

This PromotionTask can then be referenced by any number of Stages within the same project:

apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
name: uat
namespace: guestbook
spec:
requestedFreight:
- origin:
kind: Warehouse
name: guestbook
sources:
stages:
- test
promotionTemplate:
spec:
vars:
- name: app
value: guestbook
- name: imageRepo
value: company/guestbook
steps:
- task:
name: standard-process

To use a common sequence of steps across multiple projects, use a cluster-scoped ClusterPromotionTask resource instead.

To learn more about this exciting feature, refer to our PromotionTasks reference doc.

🌊 Soak Time​

A frequent request from users has been to support an option whereby a Stage may require any Freight promoted to it to have first "soaked" (remained in) an upstream Stage for a certain period of time, and this is now possible in v1.2.0.

apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
name: uat
namespace: guestbook
spec:
requestedFreight:
- origin:
kind: Warehouse
name: guestbook
sources:
stages:
- test
requiredSoakTime: 1h
promotionTemplate:
# Omitted for brevity...

Note that requiredSoakTime, if specified, is in addition to the usual criteria that Freight must have been verified upstream before becoming available for promotion.

🪜 New and Updated Promotion Steps​

  • A new json-update allows for performing updates to JSON files in the same manner that has been possible for YAML files using the yaml-update step.

  • A new delete promotion step can be used to delete files or directories.

  • Thanks to the diligent efforts of @diegocaspi, the git-open-pr and git-wait-for-pr promotion steps now support Azure DevOps repositories.

  • @muenchdo generously contributed two new options for the git-open-pr promotion step to specify a user-defined title and user-defined labels for the PRs it opens.

Refer to the Promotion Steps reference doc for more details.

🖥️ UI Improvements​

The two most notable UI improvements in v1.2.0 are:

  • When viewing a Stages verification history, it is now possible to filter out "implicit" verification records that are created when a Stage lacking any user-defined verification process simply becomes healthy with any new Freight that has been promoted to it.

  • Project-scoped Kubernetes Secrets can now be managed in the UI.

⚙️ Chart Improvements​

We've, several times now, encountered users who are terminating TLS somewhere "upstream" from the Kargo API server (for instance at a reverse proxy or load balance). This has tended to impose some difficulty as the API server, itself not being configured to terminate TLS, would be unaware that any URLs it generates should begin with https:// regardless.

To address this, we've introduced a new api.tls.terminatedUpstream that can be set to true at install time.

For further information, please refer directly to the Kargo Helm chart's README, which describes all configuration options in detail.

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

  • @diegocaspi
  • @ggogel
  • @magisystem0408
  • @RohanMishra315
  • @Sebast1aan
  • @Sobuno

Full Changelog: https://github.com/akuity/kargo/compare/v1.1.2...v1.2.0