v0.3.115: fix(deps): update node.js to v24.10.0 (#338)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

v0.3.114: chore(actions): update actions/stale action to v10.1.0 (#336)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

v0.3.113: fix(deps): update node.js to v24.9.0 (#334)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

v0.3.112

add sap-cs-devops label

v0.3.111

scaffold: bump versions (#332)

v0.3.110

fix(deps): update module github.com/prometheus/client_golang to v1.23…

v0.3.109: fix(deps): update module github.com/onsi/ginkgo/v2 to v2.25.2 (#323)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

v0.3.108: fix(deps): update non-minor dependencies (#318)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

v0.3.107

Enhancements

Status handling

So far, the observed generation of dependent objects was expected at status.observedGeneration. Some newer projects seem to populate status.conditions[type=*].observedGeneration, additionally, or even exclusively.

Starting with this release, if a status hint of has-observed-generation is present, but no status.observedGeneration is found, the framework will look at .status.conditions[type=Ready].observedGeneration as a fallback.

Secret handling

It is well known that the stringData field of secrets is not handled properly during server-side-apply:

Note:
The stringData field for a Secret does not work well with server-side apply.

To overcome, we will now merge stringData into data before applying and clear stringData. This should be consistent with the logic that would otherwise happen in the API server:

All key-value pairs in the stringData field are internally merged into the data field. If a key appears in both the data and the stringData field, the value specified in the stringData field takes precedence.

See #313.

Deletion handling

It is difficult to move dependent objects from one component to another. That means: adding it to the source manifest of the new one, and removing it from the sources of the old one.

The typical flow looks like this:

• ensure that the receiving component (the new owner) is reconciled before the sending component (the previous owner)
• annotate the dependent object (in the manifest source used by the new component) with adoption-policy: always, at least for a certain time, until the change is rolled out everywhere.

Then, when applying that, the new component will force-adopt the existing object, and the old component will run into an owner conflict error. This either has then to be solved manually by patching the old component's inventory, or (in a previous apply), the object must have been applied by the old component with delete-policy: orphan or delete-policy: orphan-on-apply.

It would be nice (and reasonable) if - upon dependent deletion, either due to component apply or component deletion - dependents with no or a different owner would be auto-orphaned. This would eliminate the need of the manual post-processing or the preflight apply run setting delete policies (as explained above).

v0.3.106: fix(go.mod/go.sum): update module sigs.k8s.io/yaml to v1.5.0 (#309)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>