v1.2.1

What's Changed

• chore(backport release-1.2): fix(directives): HTTP repo cache helm-chart-update by @akuitybot in #3330
• chore(backport release-1.2): fix(cmd): improve Argo integration checks by @akuitybot in #3349
• chore(backport release-1.2): refactor: change generic secret label by @akuitybot in #3350

Full Changelog: v1.2.0...v1.2.1

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

v1.2.0-rc.1

feat: allow project scoped generic kubernetes secrets (#2975)

Signed-off-by: Mayursinh Sarvaiya <[email protected]>
Signed-off-by: Kent Rancourt <[email protected]>
Co-authored-by: Kent Rancourt <[email protected]>

v1.1.2

What's Changed

• chore(backport release-1.1): fix(controller): do not normalize urls when searching for image creds by @akuitybot in #3114
• chore(backport release-1.1): fix(controller): expressions: fix quote() of a json object by @akuitybot in #3116
• chore(backport release-1.1): fix(controller): git-push step: pull --rebase before push by @akuitybot in #3153
• chore(backport release-1.1): fix(controller): fix tricky expr evaluation cases dealing with quotes and newlines by @akuitybot in #3186

Full Changelog: v1.1.1...v1.1.2

v1.1.2-rc.2

chore(backport release-1.1): docs: authorizing kargo stages to modify…

v1.1.2-rc.1

chore(deps): bump the go-patch group across 1 directory with 9 update…

v1.1.1

What's Changed

• chore(backport release-1.1): fix(docs): typos in promition steps causing examples to not work by @akuitybot in #3087
• chore(backport release-1.1): fix(controller): Promotion on verification failure by @akuitybot in #3099
• chore(backport release-1.1): fix(controller): app sync fix by @akuitybot in #3101
• chore(backport release-1.1): chore(deps): bump the go-patch group with 8 updates by @hiddeco in #3102
• chore(backport release-1.1): chore(deps): bump golang from 1.23.3-bookworm to 1.23.4-bookworm by @hiddeco in #3103
• chore(backport release-1.1): fix(controller): make app patch affect status.operationState by @akuitybot in #3105
• chore(backport release-1.1): fix: broken link by @akuitybot in #3106

Full Changelog: v1.1.0...v1.1.1

v1.1.1-rc.1

chore(backport release-1.1): fix: broken link (#3106)

Co-authored-by: Faeka Ansari <[email protected]>

v1.1.0

💪 The Kargo team, with support from community contributors, is proud to present v1.1.0 -- Kargo's first minor but mighty release since going GA.

🆕 What's New?

${{ Expression Language Support }}

The community reception to Kargo's transition away from its rigid, legacy promotion mechanisms, toward more flexible promotion steps has been overwhelmingly positive. When promotion steps first appeared in v0.9.0, we knew immediately that support for an expression language would be a powerful complement to that new feature, and this release delivers on that.

For more details, consult our expression reference documentation. Examples in our promotion steps reference documentation have also been extensively updated to reflect realistic usage of the expression language.

With the advent of expression language support in promotion steps, we're noticing our own promotions processes becoming more and more similar from Stage to Stage -- often varying only in the definition of a few key variables. With this observation, it's clear that the time is right to promote (pun fully intended) promotion processes to a first-class construct. So, to tease the upcoming v1.2.0 release, expect to see a new PromotionTemplate CRD that will enable users to DRY up their pipelines!

🪜 New and Updated Promotion Steps

‼️ This section contains important details about deprecations. ‼️

When promotion steps were initially introduced without expression language support, many promotion steps included fields explicitly designed to reference the output of previous steps. For example, the git-wait-for-pr step has a prNumberFromStep field whose value should be set to the alias of a previous git-open-pr step. With expressions, these sort of highly-specialized fields become unnecessary and have been deprecated and scheduled for removal in v1.3.0. In their place, are new fields that, combined with expressions, offer improved flexibility. The aforementioned git-wait-for-pr step, for example, now has a prNumber field whose value might be set using an expression such as ${{ outputs['open-pr'].prNumber }}.

Two new promotion steps have been added in this release:

• yaml-update, with the help of expressions, presents a more generic and flexible alternative to the helm-update-image step, which is also now deprecated and scheduled for removal in v1.3.0.

• http provides a flexible means of interacting with HTTP/S endpoints. This opens up the possibility of simple, low-level integration with external systems that support webhooks or expose RESTful APIs. It is easy, for instance, to use the http step to post a message to a Slack channel as part of a promotion process.

  While we plan for more complex integrations with external systems to be phased in over a series of releases in the form of support for third-party or site-specific promotion steps, we believe that in the interim, the http step will provide a powerful and flexible means of integrating with a wide variety of systems.

Two steps have been updated:

• argo-cd-update has undergone some behavioral changes. Until now, the step, which registers health checks to be performed in the course of Stage reconciliation, has automatically attempted to infer a specific desired revision (e.g. a Git commit SHA) to which the Application being updated should be observably synced to in order for the Stage to be considered healthy. This behavior has been the foundation of some difficulty for users who have multiple Applications tracking the head of a single branch and who update that branch from multiple Stages. Under such circumstances, it becomes impossible for all such Stages to be healthy simultaneously.

  To correct for this, the argo-cd-update step now makes no attempt to automatically infer the desired revision and will only factor the revision to which an Application is synced into a health check when the desired revision has been explicitly specified in the step's configuration. This change in behavior is technically a breaking change, but as it relaxes a constraint rather than imposing a new one, we do not anticipate any significant impact to existing uses of the step.

• git-open-pr has been prone to errors when a PR identical to the one it attempts to create already exists. There were a variety of complex conditions that may have precipitated such a scenario. The step (and parts of the step execution engine) have been refactored to make the step more resilient to this possibility. When a PR identical to the one the step intends to create already exists, the step will now simply "adopt" that PR and proceed as if successful.

Last, but not least, all steps can now be configured with an optional timeout and error threshold. An error threshold greater than the default of one specifies the number of consecutive failed attempts to execute the step must occur before the entire Promotion is failed.

Please refer to the promotion steps reference documentation for detailed information about new and updated promotion steps as well as deprecated steps and fields.

⚙️ Resource and Concurrency Settings

This release introduces a number of optimizations to Kargo's resource utilization.

• GOMAXPROCS is now set on all Kargo components to equal the CPU cores available, rounded up to the nearest integer. This prevents Go from backing goroutines with a number of OS threads exceeding the number of cores available, which is a condition that can result in losing compute time to avoidable context switches.

• GOMEMLIMIT (soft memory limit) is now set on all Kargo components to equal the container's memory limit. This helps Go to optimize garbage collection.

• MaxConcurrentReconciles now defaults to four (instead of one) for all reconcilers in both the controller and management controller. These defaults are overridable on a per-controller or per-reconciler basis via chart configuration at install-time.

To assist in troubleshooting, effective values for all of the above are logged by each component at startup.

🛠️ Refactored Stage Reconciliation

The controller's Stage reconciliation logic has been overhauled from top to bottom. The new implementation is more robust, more efficient, and should prove easier to maintain over time. We anticipate the refactored reconciler to also reduce the incidence of inconvenient behaviors such as pending Promotions being "stuck" for long periods of time while waiting for a Stage to reach or return to a healthy state that it may never reach.

For the most part, these changes are purely internal, but users may notice that the reconciler now surfaces much more detailed information about the state of a Stage in its status subresource in the form of conditions. These should paint a clearer picture of what's happening with a Stage at any given time.

🖥️ UI Improvements

As always, the Kargo UI has received too many improvements to list in this release. Here are a few highlights:

• New Warehouses can now be interactively configured using a new UI wizard.

• The UI's homepage, which lists all Kargo Projects, now remembers what page of the paginated list the user was last viewing. This means that users returning to the homepage after navigating to a Project will be returned to the same page of the list they were viewing before.

• Within the view of a single Project, it is now possible to zoom in/out on the pipeline graph and drag to reposition it. This should make it considerably easier to work with long pipelines or Projects containing many pipelines.

• A new user information page accessible from the sidebar displays the currently logged-in user's claims obtained from the identity token issued by the configured' OIDC identity provider. We anticipate this page will be useful for debugging OIDC configuration issues as well as authorization issues.

🙏 New Contributors

Thank you to the following community members whose first contributions to Kargo were included in this release:

• @ntheanh201
• @ddeath
• @sergiofteixeira
• @Historyman

Full Changelog: v1.0.4...v1.1.0

v1.1.0-rc.5

chore(backport release-1.1): chore: clear app status op state (#3073)

Co-authored-by: Kent Rancourt <[email protected]>
Co-authored-by: Hidde Beydals <[email protected]>