-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: debug status badge #25152
feat: debug status badge #25152
Conversation
Thanks for taking the time to open a PR!
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mostly looks good to me, I don't see any obvious issues. The new UI designs sure do look good.
watch(() => props.isNavBarExpanded, async () => { | ||
if (props.badge) { | ||
transitioning.value = true | ||
await promiseTimeout(125) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a variable we can share? How did you arrive at 125?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The animations are driven off of tailwind classes like duration-300
. 125 felt right, I didn't want it to disappear for too long, just enough for it not to thrash
<template> | ||
<SidebarNavigation | ||
:gql="query.data.value" | ||
:is-loading="query.fetching.value" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice refactor 👍
|
||
cy.percySnapshot('Debug Badge:errored') | ||
}) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now we've got Vite 4, we should definitely get Vitest in - testing this complex logic via components makes reviewing a bit challenging. It looks like you've covered all the cases, though, which is great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might have to steal some of the gql-testing infra if we implement vitest as this logic is heavily tied to gql
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could probably decouple the logic from the UI - and just keep the component tests to make sure it's all wired up correctly. Anyway, another battle for another day.
Test summaryRun details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
Not sure if this is in scope but I'm seeing some weird stuff when I load the app (when I'm logged into production cloud). The debug status badge flickers to different statuses for a few seconds and then eventually lands on one. I'm also seeing the banner that says I don't have a connection to the cloud... I think I've been seeing this recently and I'm not sure if it's related at all. Not sure what's going on there |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Most of my comments are just questions. My suggested change for the messages in en-US.json
are the only mandatory changes and updating the tests to go along with that. Going to go ahead and approve expecting that part to be done before merging to the feature branch.
// Set to February 15, 2023 to see this fail | ||
cy.clock(new Date('February 20, 2023')) | ||
mountComponent() | ||
cy.findByLabelText('New Debug feature').should('not.exist') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use messages imported fromdefaultMessages
instead of hardcoded strings in these tests. I am proposing a change to these strings in the locale file and this would keep future changes in sync
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not the biggest fan of this, though this has been discussed in the past. For example, how do I assert that the label is Last recorded run had 1 test failure
? Do I write defaultMessages.sidebar.debug.failed.split(' | ')[0].replace('{n}', 1)
. Tests should be explicit, not have the misdirection of referencing some variable and then having to add logic to make sure it works. I know this is an edge case but the only pro for referencing defaultMessages
is that I don't have to update the test when I change the text which is not worth it IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, I find it really difficult to read and search for specs that import the i18n file. If anything, doesn't not importing it give us more coverage? If we change the text in the i18n file, we will intentionally need to update the relevant tests, etc.
@@ -48,6 +47,14 @@ | |||
> | |||
{{ name }} | |||
</span> | |||
<span |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about pulling this out into its own component? Any reason that it could not stand on its own?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to do this but I couldn't get the animation to work properly due to the component getting destroyed. It's not a lot of logic and makes sense in the context of the row so I'm ok with how it is.
yeah, seems like whenever I'm on this feature branch I see that banner saying that there isn't a collection to cloud. Is that expected at this point? |
@astone123 I'll look into this a bit, I've seen it as well but I've never been able to reproduce it when I'm connected to my locally running dashboard. Running |
@ZachJW34 yeah that's what it seems like. Probably nothing to worry about then 👍🏻 |
DRAFT: Need to add spider icon to design system and incorporate
User facing changelog
Adds status badge to Debug Sidebar, indicating the results of the latest run.
Additional details
Did some refactoring of the
SidebarNavigation.vue
component, lifting the queries up to a container component to make the component easier to test.Steps to test
Driven mostly off of the CT tests, if you have
cypress-services
configured locally you can:feature/CYCLOUD-665-IATR
and runyarn
yarn docker-compose && yarn dev
localhost:3000
and create a projectCYPRESS_INTERNAL_ENV=development yarn cypress:open
projectId
npx cypress run --record --key <RECORD_KEY>
runByNumber(runNumber: 6) {
to whatever run you want to target (not dynamic yet)How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?