HYPERFLEET-1178 - test: add Ready condition absence integration test

[pnguyen44]

Summary

HYPERFLEET-1178

Adds an integration test that verifies v1.0.0 status aggregation does not produce a resource-level
Ready condition. Partners polling for Ready=True would hang indefinitely; the correct conditions
are Reconciled and LastKnownReconciled. This is part of the v1.0.0 adapter contract-conformance
testing effort driven by the breaking-change checklist from HYPERFLEET-1177.

Changes

• Added integration test that submits a fully-reconciled adapter status (Available, Applied, Health,
  Reconciled all True), then asserts that no Ready condition appears in the aggregated resource-level
  conditions
• Verifies that Reconciled and LastKnownReconciled conditions are present after successful
  aggregation, confirming the v1.0.0 contract

Test Plan

• Unit tests added/updated
• make test-all passes
• make lint passes
• Helm chart changes validated with make test-helm (if applicable)
• Deployed to a development cluster and verified (if Helm/config changes)
• E2E tests passed (if cross-component or major changes)

[coderabbitai]

📝 Walkthrough

Walkthrough

A new integration test, TestClusterStatusPut_ReadyConditionAbsentAfterReconciliation, is added to test/integration/adapter_status_test.go. The test creates a cluster, submits an adapter status update with Reconciled=True along with Available, Applied, and Health set to True, then retrieves the cluster and asserts that no Ready condition appears in cluster.status.conditions while both Reconciled and LastKnownReconciled resource conditions are present.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 11

✅ Passed checks (11 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately identifies the new integration test for the Ready condition absence.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Sec-02: Secrets In Log Output	✅ Passed	PASS: No non-test/non-example Go log statements with token/password/credential/secret terms were found; changed code is test-only. CWE-532.
No Hardcoded Secrets	✅ Passed	No hardcoded secrets in the added test; no secret literals, embedded credentials, base64 blobs, or private keys found. CWE-259 not triggered.
No Weak Cryptography	✅ Passed	No banned primitives, custom crypto, ECB, or secret comparison logic in the only changed file; patch is a test-only addition. No CWE-327/328/916 signal.
No Injection Vectors	✅ Passed	Only added code is a test file; no SQL/exec/template/yaml sinks, and the new test uses hardcoded/enum inputs. CWE-89/78/79/502 not present.
No Privileged Containers	✅ Passed	No CWE-250 issue: Dockerfile root use is justified in builder stage; runtime drops to UID 65532, and chart defaults stay non-root with allowPrivilegeEscalation=false.
No Pii Or Sensitive Data In Logs	✅ Passed	No added slog/logr/zap/fmt.Print* calls in the changed test; no CWE-532 logging exposure risk found.
Description check	✅ Passed	The description matches the change set: it adds an integration test covering absence of the Ready condition after status aggregation.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

✨ Simplify code

• Create PR with simplified code

---

_{Comment @coderabbitai help to get the list of available commands.}

[hyperfleet-ci-bot]

Risk Score: 0 — risk/low

Signal	Detail	Points
PR size	66 lines	+0
Sensitive paths	none	+0

_{Computed by hyperfleet-risk-scorer}

[kuudori]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kuudori

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [kuudori]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment