Handle Jobs with ttl_seconds_after_finished = 0 correctly

[JaylonmcShan03]

Description

Fixes #2531 When a Kubernetes Job has ttl_seconds_after_finished set to 0, Kubernetes deletes the Job immediately after it completes. This can cause Terraform to plan the recreation of the Job in subsequent runs, which is sort of undesirable behavior. The expected behavior is for Terraform to recognize that the Job was deleted intentionally and not attempt to recreate it or show any diffs.

Changes made - Read function: - When the read crud func encounters a NotFound error for a job, it now checks if ttl is set to 0, if so it keeps the resource in the state without marking it as destroyed, this helps prevent the recreation of the job. If it is not 0, it behaves as before by removing the resource from the state.

CustomizeDiff function introduced: - Supressing diffs when the job has been deleted due to due to ttl = 0

Acceptance tests

• [x] Have you added an acceptance test for the functionality being added?
• [x] Have you run the acceptance tests on this branch?

Output from acceptance testing:

└─(10:13:50 on fix-job-ttl-zero-handling)──> make test TESTARGS="-run TestAccKubernetesJobV1_customizeDiff_ttlZero"
==> Checking that code complies with gofmt requirements...
go vet ./...
go test "/Users/mau/Dev/terraform-provider-kubernetes/kubernetes" -vet=off -run TestAccKubernetesJobV1_customizeDiff_ttlZero -parallel 8 -timeout=30s
ok      github.com/hashicorp/terraform-provider-kubernetes/kubernetes   0.924s
...

Release Note

Release note for CHANGELOG:

Properly handle Kubernetes Jobs with ttl_seconds_after_finished = 0 to prevent unnecessary recreation.

References

Fixes #2531

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment