Kargo v1.12.0

Changes

• !·The Connect-Based (gRPC) API Has Been Removed (#6617): As announced in the v1.9.0 release notes and reiterated in the v1.11.0 release notes, the Connect-based gRPC API is gone. The UI completed its migration to the REST API in v1.11.0, so the legacy API had no first-party consumers left. If you maintain integrations built against it, migrate them to the REST API before upgrading. Upgrade the CLI to v1.12.0 alongside your server -- older CLIs may still reach for endpoints that no longer exist.other / breaking
• !·CreateTargetBranch Removed from the git-open-pr Step (#6916): Deprecated in v1.10.0, the createTargetBranch option has been removed. The feature never actually worked; see #5847 for the details. Remove the field from any promotion steps or promotion tasks that still set it.other / breaking
• !·Author Removed from the git-commit Step (#7314): Also deprecated in v1.10.0, the author block (name, email, and signingKey) has been removed from git-commit. Authorship and commit signing are configured once, on the git-clone step or in ClusterConfig, and apply to every commit made in that working tree. See the git-commit docs for details.other / breaking
• !·Git-push Defaults to RebaseOrMerge (#7319): As announced in v1.10.0, the default push integration policy for the git-push and github-push steps has changed from AlwaysRebase to RebaseOrMerge. Unconditionally rebasing onto a remote that has moved ahead rewrites commits, and rewriting a signed commit either strips its signature or re-signs it as someone else. RebaseOrMerge rebases only when it can tell that's safe and otherwise integrates with a merge commit. To keep the old behavior, set controller.gitClient.pushIntegrationPolicy: AlwaysRebase in your Helm values. See Push Integration Policy.other / breaking
• !!Legacy Secret Namespace Settings Now Fail the Upgrade (#7320): v1.9.0 replaced the "cluster secrets namespace" and "global credentials namespaces" with the system resources and shared resources namespaces, and shipped a controller that kept Secret s in sync between the old and new locations while you transitioned. That bridge is gone. The chart values global.clusterSecretsNamespace, global.createClusterSecretsNamespace, global.createClusterSecretsRBAC, and controller.globalCredentials.namespaces have been removed, and a helm install or helm upgrade that still sets either legacy namespace fails with a message explaining what to do. Before upgrading, confirm the Secret s you rely on already exist in the namespaces named by global.systemResources.namespace and global.sharedResources.namespace -- especially if you manage them with a GitOps agent, since Kargo will no longer copy them for you. See Migrating from Kargo < 1.9.0.security / breaking
• !·Image Creation Times Are Read Differently (#6777): Kargo previously preferred an image's org.opencontainers.image.created or org.label-schema.build-date label over the creation time recorded in its config. Labels are inherited from the base image unless a build overwrites them, so an image that sets no label of its own reported the build time of the image it was built from -- and every image built from the same base between two republishes of that base reported an identical time. With the NewestBuild image selection strategy, those ties fell back to reverse lexical tag order and were then truncated to discoveryLimit, so genuinely new images could go undiscovered rather than merely mis-ranked.other / breaking
• !Cross-Account ECR: Kargo can now pull image metadata from an Elastic Container Registry in a different AWS account than the controller's. Role assumption is attempted in order -- kargo-project-<project name> in the registry's account, then the same role in the controller's account, then the controller's own role -- so Project-level isolation is preserved instead of silently collapsing to a shared role. (docs,security
• !Who Did That?: Every API server request log line now names its actor -- admin, email:..., or kubernetes:system:serviceaccount:... -- in the same form already used to attribute Promotions and events. API tokens leave a trail too: a new token's Secret is annotated with who minted it, and APITokenCreated and APITokenDeleted events record the token's name, Role, and actor. (docs,security
• +Package and Push Local Artifacts: The new tar step archives a file or directory from the promotion workspace (gzipped by default), and the oci-push step gained a srcPath option that uploads a local file as a proper OCI 1.1 artifact -- streamed from disk, with a top-level artifactType mirrored onto the config media type for Flux, Helm, and ORAS compatibility. Together they close the loop: render manifests during a promotion, package them, and publish them to a registry for a GitOps agent to sync. (#6666,added
• +Http Step Bodies from Files: A new bodyFromFile option takes the request body from a path in the promotion work directory, so a payload produced by an earlier step no longer has to be squeezed through an inline expression. Mutually exclusive with body. (docs,added
• +Clean Up After git-merge-pr: Pipelines that chain git-open-pr and git-merge-pr leave a kargo/promotion/<promotion name> branch behind for every promotion, and GitHub's "automatically delete head branches" setting ignores merges performed with a GitHub App installation token -- which is how Kargo authenticates when given GitHub App credentials. A new deleteSourceBranch option deletes the PR's source branch after a successful merge, on every supported provider. Because the merge is the step's real job, a failed deletion is reported in the step's message rather than failing the step. (docs,added
• +RepoCredentials() Expression Function: secret() returns the raw contents of a Secret selected by name, which is no help when the credentials you actually need are minted on the fly -- a GitHub App installation token, say, or a cloud provider's ambient credentials. The new repoCredentials(repoURL, type) function resolves credentials for a Git, Helm, or image repository by URL through the same machinery built-in steps like git-clone use, returning a username, password, and sshPrivateKey. Custom and generic steps, such as an http step calling a provider's API, can finally authenticate the way built-in steps do. (docs,added