Reading #542 I see we miss a test for that use case.
So I added one and the test passes as expected.
Perhaps there was a bug in the jsonpatch library we're using at the time
🤷
This augments the injection codegen with the capability to produce a duck.InformerFactory
attached to context for each type that we process.
Now a `duck.InformerFactory` for "Addressable" can be produced by "Get"ing it from the context.
This is triggered by placing `// +genduck` on the type that implements `duck.Implementable`.
We have been maintaining a copy of this helper function in the Knative
Serving tests. Moving it here and adding tests so it can be used more
generally. The function allows creating a []byte patch without having to
check two levels of error conditions.
My prior change added sorting to the duck.CreatePatch method to try and stabilize the result of jsonpatch.CreatePatch, which is otherwise non-deterministic (probably walking a map?).
My bad assumption was that the patch operations this generated wouldn't conflict, e.g. it should use `replace` vs. `remove` and `add`.
Clearly this was bad because we start getting really strange errors trying to import this into knative/serving, e.g.
https://gubernator.knative.dev/build/knative-prow/pr-logs/pull/knative_serving/2646/pull-knative-serving-integration-tests/1070435951391543298/
Immutable fields with default values may now be changed iff they change is to populate their default value. This is to support defaulting in the scenario where an object was created long ago and a new field (with a default!) is added. When controllers attempt to mutate the object status today, this would create a webhook rejection! With this change, we compare against a freshly defaulted "old" object to exclude newly defaulted fields from the immutability check.
We saw this in knative/serving for the newly added TimeoutSeconds field in Revision (otherwise immutable), which I believe it leading to upgrade testing flakes since post-upgrade Revision status updates will fail.