Added timestamps support for deployment logs #4481

DobromirM · 2022-10-06T16:29:13Z

Description

Fixes #4470
Added timestamps support for deployment logs and other resources.

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

DobromirM · 2022-10-06T16:30:03Z

Fixes #4470

shawkins

LGTM

The initial pr comment mentions this is a breaking change. Can you elaborate on what behavioral changes this causes?

DobromirM · 2022-10-11T14:04:18Z

@shawkins Some of the changes are on public classes / interfaces so if anyone is using them directly it will break. For example if you have a custom resource that extends interface ScalableResource<T> then you will need to add the new methods. As far as I am aware this change does not introduce any breaking changes to the k8s client interface itself.

shawkins · 2022-10-11T16:44:42Z

For example if you have a custom resource that extends interface ScalableResource then you will need to add the new methods.

Thanks for the explanation. We generally won't worry about that case - especially for a minor release.

Added timestamps support for deployment logs and other resources.

manusa · 2022-10-19T08:34:28Z

For example if you have a custom resource that extends interface ScalableResource then you will need to add the new methods. As far as I am aware this change does not introduce any breaking changes to the k8s client interface itself.

Is this something someone might be actually doing? if so we should probably consider moving those interfaces to an internal package.