feat: Add typed scale argument to derive macro

[Techassi]

Motivation

Customizing the scale subresource via #[kube(scale = r#"{}"#)] can feel very out-of-place and requires writing a raw JSON string. In addition, this can lead to a very long line, eg:

#[kube(
    version = "v1alpha1",
    kind = "MyScaler",
    namespaced,
    scale = r#"{"specReplicasPath": ".spec.replicas", "statusReplicaPath": ".status.replicas", "labelSelectorPath": ".spec.labelSelector"}"#
)]
struct ScalerSpec {}

Solution

This allows customizing the scale subresource by providing key-value items instead of a raw JSON string. For backwards-compatibility, it is still supported to provide a JSON string. However, all examples and tests were converted to the new format.

#[kube(
    version = "v1alpha1",
    kind = "MyScaler",
    namespaced,
    scale(
        specReplicasPath = ".spec.replicas",
        statusReplicaPath = ".status.replicas",
        labelSelectorPath = ".spec.labelSelector"
   )
)]
struct ScalerSpec {}

[codecov]

Codecov Report

Attention: Patch coverage is 4.08163% with 47 lines in your changes missing coverage. Please review.

Project coverage is 75.1%. Comparing base (60d3ebc) to head (a36d0bd).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
kube-derive/src/custom_resource.rs	4.1%	47 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1656     +/-   ##
=======================================
- Coverage   75.6%   75.1%   -0.4%     
=======================================
  Files         82      82             
  Lines       7405    7453     +48     
=======================================
+ Hits        5591    5592      +1     
- Misses      1814    1861     +47     

Files with missing lines	Coverage Δ
kube/src/lib.rs	88.5% <ø> (ø)
kube-derive/src/custom_resource.rs	67.2% <4.1%> (-15.2%)	⬇️

[clux]

Hey there. Thanks for this! Apologise for the delay.

I think this makes sense, given you've made it non-breaking, but ideally the dependency on the openapi crate should be severed if it's just for the interface. Have added a few suggestive comments.

[clux]

this feels unfortunate. don't really want a derive crate (which is hard to optimise compile wise) to depend on such a big crate.

[clux]

if the dependency is just for this struct, then maybe we should inline that for the interface instead. It would also avoid having to do the newtyping you do below.

[clux]

Maybe there's a way to add a deprecated message to the old way?

[Techassi]

Apologise for the delay.

No worries. I will shortly take a look at your comments. I will also see if we can get rid of the k8s_openapi dependency.