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: v1.1.2...v1.2.0