Add further patch mechanisms #229
Conversation
kennethito
force-pushed
the
operation-header-params
branch
from
6e8d2d6
to
1e0de48
Compare
lib/k8s/operation.ex
Outdated
| defstruct method: nil, | ||
| verb: nil, | ||
| api_version: nil, | ||
| name: nil, | ||
| data: nil, | ||
| conn: nil, | ||
| path_params: [], | ||
| query_params: [] | ||
| query_params: [], | ||
| header_params: [] |
There was a problem hiding this comment.
How about we define a default here so we can safely remove the code in base.ex? Just a thought. Would have to run tests.
| header_params: [] | |
| header_params: ["Content-Type": "application/json"] |
There was a problem hiding this comment.
I did add this, and mix test is succeeding. I do think there is a case, where if an application was creating the Operation struct themselves, without using build, where this would be a breaking change if the Operation was a patch or apply, since it was the Client.Runner.Base that was setting these headers before. That seems like it would be really rare though?
|
Oops, didn't realize pushing a commit would clear the workflow results. Basically everything passed except the mix format --check-formatting step. |
|
Credo not happy about complexity. But that's okay, I can take it from here. Will merge and fix Credo. Thanks for your work, @kennethito! |
|
Credo fixed in 7d2c744 (and a tiny refactoring) |
Niceee, I like it. |
|
Integration tests would have been nice! |
Adds Operation.header_params which are used with K8s.Client.patch and K8s.Client.apply, allowing for alternate patch types.
Resolves #227