fix(deps): update non-minor dependencies

[renovate]

This PR contains the following updates:

Package	Type	Update	Change	Age	Confidence
docker.io/bitnami/kubectl (source)		patch	1.33.1-debian-12-r3 -> 1.33.4-debian-12-r0
docker.io/bitnami/os-shell (source)		patch	12-debian-12-r46 -> 12-debian-12-r51
github.com/sap/admission-webhook-runtime	require	patch	v0.1.66 -> v0.1.69
github.com/sap/component-operator-runtime	require	patch	v0.3.101 -> v0.3.111
github.com/sap/go-generics	require	patch	v0.2.32 -> v0.2.38
golang	stage	patch	1.25.0 -> 1.25.1
sigs.k8s.io/controller-runtime/tools/setup-envtest	require	digest	8f791a2 -> 157e6d2

---

Release Notes

sap/admission-webhook-runtime (github.com/sap/admission-webhook-runtime)

v0.1.69

Compare Source

v0.1.68

Compare Source

v0.1.67

Compare Source

sap/component-operator-runtime (github.com/sap/component-operator-runtime)

v0.3.111

Compare Source

v0.3.110

Compare Source

v0.3.109

Compare Source

v0.3.108

Compare Source

v0.3.107

Compare Source

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 SAP#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

Compare Source

v0.3.105

Compare Source

v0.3.104

Compare Source

v0.3.103: v03.103

Compare Source

Bug fixes

Fixes #​305.

v0.3.102

Compare Source

Bug fixes

This release fixes #​302.

sap/go-generics (github.com/sap/go-generics)

v0.2.38

Compare Source

v0.2.37

Compare Source

v0.2.36

Compare Source

v0.2.35

Compare Source

v0.2.34

Compare Source

v0.2.33

Compare Source

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

• 13 additional dependencies were updated

Details:

Package	Change
github.com/onsi/gomega	v1.37.0 -> v1.38.0
golang.org/x/mod	v0.24.0 -> v0.25.0
sigs.k8s.io/yaml	v1.4.0 -> v1.6.0
github.com/fxamacker/cbor/v2	v2.8.0 -> v2.9.0
github.com/google/gnostic-models	v0.6.9 -> v0.7.0
github.com/modern-go/reflect2	v1.0.2 -> v1.0.3-0.20250322232337-35a7c28c31ee
golang.org/x/sync	v0.14.0 -> v0.15.0
golang.org/x/text	v0.25.0 -> v0.26.0
golang.org/x/tools	v0.32.0 -> v0.33.0
k8s.io/gengo/v2	v2.0.0-20250207200755-1244d31929d7 -> v2.0.0-20250604051438-85fd79dbfd9f
k8s.io/kube-openapi	v0.0.0-20250318190949-c8a335a9a2ff -> v0.0.0-20250710124328-f3f2b991d03b
k8s.io/utils	v0.0.0-20250502105355-0f33e8f1c979 -> v0.0.0-20250604170112-4c0f3b243397
sigs.k8s.io/structured-merge-diff/v6	v6.1.0 -> v6.3.0

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.