Skip to main content
Version: 0.7 (Next)

Konstruct 0.6.12

Released: August 2026

Highlights​

  • Fixed: a deleted management cluster's name could never be reused — name validation now frees a name once its cluster is fully torn down, while still reserving it for the whole teardown
  • Fixed: catalog deployments could get stuck and never report as deployed — a clean git tree is now treated as converged instead of an error, and a stale reconcile can no longer regress status another reconcile already wrote

Fixed: a deleted management cluster's name could never be reused​

The cluster name validation for management clusters counted a name as taken when any project carried it — including projects whose cluster had already been deleted. Once a management cluster was deleted, its name stayed permanently reserved and could never be used again.

Validation now checks the project's lifecycle phase: a name is free to reuse once its project reaches the terminal deleted phase — that is, the operator has fully torn the cluster down, including its Argo CD application, GitOps repository content, and cloud infrastructure.

The name stays reserved for the entire teardown on purpose. Management cluster names are globally unique and infrastructure keys off the name, so freeing it the moment deletion is requested would let a new cluster reuse the name while the old one's GitOps content and infrastructure are still live. The name is released only at the safe point, when nothing of the old cluster remains.

Fixed: catalog deployments could get stuck and never report as deployed​

Two related problems could leave a GitOps catalog deployment permanently stuck, never reaching its deployed state even though its content was in the GitOps repository:

  • A clean git tree was treated as an error. When the operator regenerated a deployment's files and found nothing to commit — for example because an earlier push had landed but the status update afterwards never persisted — it reported "no changes to commit" as a failure and retried forever. A clean tree after regenerating the complete file set means the GitOps repository already contains exactly this deployment's content; the operator now treats that as convergence and marks the deployment deployed.
  • A stale reconcile could overwrite newer status. Concurrent reconciles raced on the deployment's status: one holding a stale copy could replace the whole status, flipping already-deployed flags back to false and wiping conditions another reconcile had just written. Status updates now merge onto the latest version of the resource — deploy flags only ever move forward, and unrelated conditions survive.

Deployments that were stuck on this loop converge on their next reconcile after upgrading — no changes to the catalog item or deployment are needed. The fix ships with unit tests covering both the flag-regression and condition-preservation cases.

Upgrade notes​

Update the targetRevision in your platform team's Konstruct Argo CD Application manifest to 0.6.12:

spec:
  source:
    chart: konstruct
    repoURL: oci://europe-west2-docker.pkg.dev/civo-com/charts
    targetRevision: 0.6.12

Commit and push — Argo CD syncs the new version automatically. No manual migration steps are required.

  • Catalog deployments stuck on "no changes to commit" recover on their own after the upgrade — no action is needed.

What's next?​