-
Notifications
You must be signed in to change notification settings - Fork 402
chore: [M3-10715] - Bump Vite and update Vitest from v3 to v4
#13119
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
Changes from 11 commits
a6aa39c
9dd65b0
ffc1933
1c3e83c
6e28a04
de91323
04fbf2f
ae92013
9f426af
b348fac
caadc44
a885ef2
7978c7f
abf6e3a
0416372
f32d18a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,5 @@ | ||
| import { linodeFactory, nodeBalancerFactory } from '@linode/utilities'; | ||
|
|
||
| import { transformDimensionValue } from '../../../Utils/utils'; | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had to move around numerous CloudPulse functions to avoid circular imports that were causing tests to intermittently fail. No logic was changed, I just had to move things around. |
||
| import { | ||
| getFilteredFirewallParentEntities, | ||
| getFirewallLinodes, | ||
|
|
@@ -11,6 +10,7 @@ import { | |
| handleValueChange, | ||
| resolveSelectedValues, | ||
| scopeBasedFilteredResources, | ||
| transformDimensionValue, | ||
| } from './utils'; | ||
|
|
||
| import type { Linode } from '@linode/api-v4'; | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -35,8 +35,6 @@ const pollingIntervalOptions = | |
| })); | ||
|
|
||
| describe('Trigger Conditions', () => { | ||
| const user = userEvent.setup(); | ||
|
|
||
| it('should render all the components and names', () => { | ||
| renderWithThemeAndHookFormContext({ | ||
| component: ( | ||
|
|
@@ -120,7 +118,7 @@ describe('Trigger Conditions', () => { | |
| { name: 'Open' } | ||
| ); | ||
|
|
||
| user.click(evaluationPeriodInput); | ||
| await userEvent.click(evaluationPeriodInput); | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not awaiting some of these |
||
|
|
||
| expect( | ||
| await screen.findByRole('option', { | ||
|
|
@@ -133,7 +131,7 @@ describe('Trigger Conditions', () => { | |
| }) | ||
| ).toBeVisible(); | ||
|
|
||
| await user.click( | ||
| await userEvent.click( | ||
| screen.getByRole('option', { | ||
| name: evaluationPeriodOptions[0].label, | ||
| }) | ||
|
|
@@ -167,7 +165,7 @@ describe('Trigger Conditions', () => { | |
| { name: 'Open' } | ||
| ); | ||
|
|
||
| user.click(pollingIntervalInput); | ||
| await userEvent.click(pollingIntervalInput); | ||
|
|
||
| expect( | ||
| await screen.findByRole('option', { | ||
|
|
@@ -181,7 +179,7 @@ describe('Trigger Conditions', () => { | |
| }) | ||
| ).toBeVisible(); | ||
|
|
||
| await user.click( | ||
| await userEvent.click( | ||
| screen.getByRole('option', { | ||
| name: pollingIntervalOptions[0].label, | ||
| }) | ||
|
|
@@ -191,7 +189,7 @@ describe('Trigger Conditions', () => { | |
| ).toHaveAttribute('value', pollingIntervalOptions[0].label); | ||
| }); | ||
|
|
||
| it('should be able to show the options that are greater than or equal to max scraping Interval', () => { | ||
| it('should be able to show the options that are greater than or equal to max scraping Interval', async () => { | ||
| renderWithThemeAndHookFormContext({ | ||
| component: ( | ||
| <TriggerConditions | ||
|
|
@@ -216,7 +214,7 @@ describe('Trigger Conditions', () => { | |
| { name: 'Open' } | ||
| ); | ||
|
|
||
| user.click(evaluationPeriodInput); | ||
| await userEvent.click(evaluationPeriodInput); | ||
|
|
||
| expect( | ||
| screen.queryByText(evaluationPeriodOptions[0].label) | ||
|
|
@@ -227,7 +225,7 @@ describe('Trigger Conditions', () => { | |
| 'button', | ||
| { name: 'Open' } | ||
| ); | ||
| user.click(pollingIntervalInput); | ||
| await userEvent.click(pollingIntervalInput); | ||
| expect( | ||
| screen.queryByText(pollingIntervalOptions[0].label) | ||
| ).not.toBeInTheDocument(); | ||
|
|
||
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.
Thanks @bnussman-akamai - reliance on timeouts can only lead to more flaky tests. Is there any better workaround? like awaiting?
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 may be able to drop the explicit
timeouton some of the test but I'm keeping them for now to try to minimize any new flake. Vitest v4 already seems to be posing some new flake that I don't know exactly how to solve right nowThere 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.
@abailly-akamai @bnussman-akamai I haven't looked at this particular case, but TBH I think a lot of our unit test CI flake is caused by performance issues stemming from JSDom + the parallelization of our tests where increasing the timeout really is the only solution in reach.
I'm only speculating because I don't know how to actually prove it, but here's an explanation of my reasoning that I shared with @HanaXu in Slack a few weeks back when she encountered a similar seemingly random unit test failure (#13015):
One reason I think this is the case is that back when I was still on my Intel MacBook, I used to be able to reproduce these types of failures locally pretty consistently by running multiple specs at a time whereas running only the failing spec would tend to pass. Since upgrading to the M3, I haven't been able to reproduce any of these types of failures, so I'm pretty confident that performance is a factor in some way.
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.
Thanks - this makes sense to me. I am less worried about these few instances than I am about proliferation of those. Could be overused by contributors once it starts spreading. But maybe that's a moot concern at this point
Uh oh!
There was an error while loading. Please reload this page.
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.
Very much acknowledge and agree with the observations on the performance issues. I experienced that first hand with my Intel Mac and we're seeing it on Akamai's internal CI runners. π
In the case of this PR, while the performance issues are likely a factor in play, I think there is more to the story. I'm seeing new flake that I haven't seen before and I'm speculating it's a symptom of Vitests new pool/threading implementation that was introduced in v4
To address this new flake, I seem to be having some success with
userEvent.click()are awaited