kubernetes-client
Incorrect User-Agent
Describe the bug When running this code:
public V1ConfigMap createOrReplace(V1ConfigMap configMap) throws ApiException
{
V1ObjectMeta metadata = configMap.getMetadata();
assert (metadata != null);
// https://github.com/kubernetes-client/java/issues/3653#issuecomment-2307770649
V1Patch configMapPatch = new V1Patch(JSON.serialize(configMap));
return PatchUtils.patch(V1ConfigMap.class,
() -> core.patchNamespacedConfigMap(metadata.getName(), metadata.getNamespace(), configMapPatch).
fieldManager(fieldManager).
force(true).
buildCall(null),
V1Patch.PATCH_FORMAT_APPLY_YAML,
client);
}
If I step through the code with a debugger, I can see that the Request object created by PatchUtils.patch() is using the wrong User-Agent version: Request{method=PATCH, url=https://fb6cde70-6232-42cf-a2e1-211ac67c62ed.k8s.ondigitalocean.com/api/v1/namespaces/default/configmaps/install-helm-script?fieldManager=LicensedCluster&force=true, headers=[authorization:Bearer redacted, Accept:application/json, Content-Type:application/json, User-Agent:Kubernetes Java Client/21.0.0-SNAPSHOT]}
I am using v22.0.0, not 21.0.0-SNAPSHOT.
Client Version
<dependency>
<groupId>io.kubernetes</groupId>
<artifactId>client-java</artifactId>
<version>22.0.0</version>
</dependency>
Kubernetes Version 1.31.1
Java Version Java 23.0.1
To Reproduce Run the aforementioned code
Expected behavior
The User-Agent should be equal to Kubernetes Java Client/22.0.0.
KubeConfig N/A
Server (please complete the following information):
- OS: Linux
- Environment: DigitalOcean Kubernetes (DOKS)
- Cloud: DigitalOcean
I think this comes from here:
https://github.com/kubernetes-client/java/blob/master/kubernetes/src/main/java/io/kubernetes/client/openapi/Configuration.java#L17
We probably need to update it before we cut a release. We'll have to figure out the best way to get that into our automation. I would have thought that mvn release:prepare would do it for us, but apparently not.
@brendandburns Why don't you embed and read the version number from the JAR file? That's much easier to do than have Maven update source-code files.
