Question: Record "Change Cause" in Rollout History

[KyleKing]

Question

I wondered if it was possible to configure the Kubernetes provider in a way that the change cause was recorded in the rollout history? I've searched through issues and the documentation and haven't come across a relevant setting, but I might be missing something.

---

To replicate, run terraform apply against an AWS EKS cluster and then check rollout history with:

kubectl rollout history deployment <deployment>

Which just returns:

REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>
4         <none>

From the kubectl documentation, the change cause can be documented by setting --record=true (https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands). I'm not sure if there is something similar in the API that this provider could or does leverage

Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists.

[jrhouston]

Just FYI the --record flag is actually being deprecated. If you wanted to replicate what this flag does, though, you can just set the kubernetes.io/change-cause annotation on the Deployment metadata like this:

resource "kubernetes_deployment" "example" {
  metadata {
    # ...
    annotations = {
      "kubernetes.io/change-cause" = "terraform apply"
    }
  }
  # ...
}

and it will show up like this:

REVISION  CHANGE-CAUSE
1         terraform apply

[KyleKing]

I wasn't aware of the annotation and that should meet our needs. Thanks!