using a strategic merge to prevent a 422

[shawkins]

Description

Addressing the integration test timing issue seen in #3136 (comment) with a strategic merge patch.

@rohanKanojia it feels a little verbose to create a patch context of a given patch type - should there be utility methods for that?

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[centos-ci]

Can one of the admins verify this patch?

[rohanKanojia]

sure, I think we can add some utility methods for PatchContext (maybe in KubernetesResourceUtil). Do you have some idea in mind with which we can improve readability?

[shawkins]

how about - PatchContext.of(patchType)

[rohanKanojia]

Sounds good to me.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[shawkins]

@manusa https://github.com/fabric8io/kubernetes-client/pull/3148/files#diff-0ae0c25ccaf88d84f2fc51e6487f7033e312ca550ce5af75ace50bdc3a75168fR90 is now the clearest expression of what you were looking for in #3078 (comment)

[manusa]

LGTM, thx!