Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug 2168484: Add dates to VM metric charts labels #1171

Conversation

pcbailey
Copy link
Member

馃摑 Description

This PR adds dates to the x-axis labels of the VM metric charts for durations that span multiple days and changes the time format for durations that do not.

馃帴 Screenshots

Multiple days format

Selection_229

Single day format

Selection_230

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 21, 2023

@pcbailey: This pull request references Bugzilla bug 2168484, which is invalid:

  • expected the bug to target the "4.14.0" release, but it targets "4.13.0" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

Bug 2168484: Add dates to VM metric charts labels

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci openshift-ci bot added the approved This issue is something we want to fix label Mar 21, 2023
@@ -3,36 +3,32 @@ import React from 'react';
import { V1VirtualMachineInstance } from '@kubevirt-ui/kubevirt-api/kubevirt';
import MigrationThresholdChart from '@kubevirt-utils/components/Charts/MigrationUtil/MigrationThresholdChart';
import MigrationThresholdChartDiskRate from '@kubevirt-utils/components/Charts/MigrationUtil/MigrationThresholdChartDiskRate';
import { useKubevirtTranslation } from '@kubevirt-utils/hooks/useKubevirtTranslation';
import { t } from '@kubevirt-utils/hooks/useKubevirtTranslation';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why did u did this change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I first started looking at the bug I thought I was going to be changing this file and went ahead and made this change to make it look cleaner. Is it a problem? They should be equivalent, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes its equal, but until now we preferred using the hook method on tsx files and simply t on ts files, to keep it organized

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrm. That's the first I've heard of that. How is unnecessary boilerplate more organized?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simply as a hook for tsx and t for ts because u cannot use hooks.
Why do we not simply use t instead of a hook also for tsx?
t will be static and not rerender like t from a hook; how much its import?
I don't know... but this is why we kept it like this so if a new reactive version of t will be needed for some reason the hook will make sure of it.
maybe static t will cause problems in static utils files in the future? I also dont know, but we can always go back to re adding t as arg to function. hope this makes sense to u

Copy link
Member Author

@pcbailey pcbailey Mar 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. The short answer is "we don't know, but better safe than sorry". lol

I'll change it back in a few.

I don't know when this convention was discussed, but I don't remember being told about it. We need to make sure that information is disseminated clearly to the whole team, especially if it's something that's been discussed in person in the office.

@pcbailey pcbailey force-pushed the add-dates-to-vm-metrics-charts branch from 438c590 to 848fd0f Compare March 22, 2023 13:34
@metalice
Copy link
Member

/lgtm

@openshift-ci openshift-ci bot added the lgtm Passed code review, ready for merge label Mar 22, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 22, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: metalice, pcbailey

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 7caa425 into kubevirt-ui:main Mar 22, 2023
8 checks passed
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 22, 2023

@pcbailey: All pull requests linked via external trackers have merged:

Bugzilla bug 2168484 has been moved to the MODIFIED state.

In response to this:

Bug 2168484: Add dates to VM metric charts labels

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved This issue is something we want to fix bugzilla/severity-medium bugzilla/valid-bug lgtm Passed code review, ready for merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants