Fix faulty ManifestCR state determination

c-pius commented 1 month ago

Description

With the ADR Mapping module deployment state to ManifestCR state we defined how we want to map the ManifestCR state from the deployment of the module. This ADR now needs to be implemented in code.

This should be a good candidate for good code design. We already have the DeploymentReadyCheck struct. Consider to improve to revisit it's interface and dependencies so that we get a nicely testable "state machine service". If re-designing this, also consider that later on we want to add state checks for StatefulSet as well.

Reasons

With https://github.com/kyma-project/lifecycle-manager/issues/1554 we introduced new ManifestCR state determination that proofed to be faulty.

Acceptance Criteria

[ ] ManifestCR state determination follows the Decision section of the ADR
[ ] Existing E2E tests extended to verify the expected state transitions from the ADR
- [ ] consider if we can include in the tests that the transitions happen quicker than the requeue success interval
[ ] ManifestCR state determination unit tested with coverage > 80%

Feature Testing

No response

Testing approach

No response

Attachments

No response

janmedrek commented 1 month ago

HINT: KLM Code - https://github.com/kyma-project/lifecycle-manager/blob/294103d856cb03a2e148c960b56ce071b02d4372/internal/manifest/deployment_ready_check.go#L44

c-pius commented 2 days ago

Re-estimated to 0 as we included it in the sprint closing on 2024-09-11.

kyma-project / lifecycle-manager