test [UIE-9634-]: Fix flakey vm-host test #13083
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description 📝
Fix the flakey vm-host test by hardcoding mock data instead of using randomly generated 'reason' which causes test to fail.
Changes 🔄
Cypress test
'maintenance notification banner on landing page for 1 linode' and 'maintenance notification banner on landing page for >1 linodes' in vm-host-maintenance-linode.spec.ts fail intermittently. Logs such as https://baker.linode.com/blue/organizations/jenkins/manager%2Fmanager-test/detail/PR-13048/10/tests/ indicate that the banner isn't showing up, and that's what the artifacts suggest as well.
The problem is that the isPlatformMaintenance hook in MaintenanceBannerV2 excludes notifications if they include the phrase "critical security update" in the reason attribute message, and this phrase is in one of the reasons randomly selected in the accountMaintenanceFactory that we use to create mock maintenance notifications. Solution is to hardcode the reason.
Scope 🚢
Upon production release, changes in this PR will be visible to:
How to test 🧪
pnpm run cy:run -s cypress/e2e/core/linodes/vm-host-maintenance-linode.spec.ts
Author Checklists
As an Author, to speed up the review process, I considered 🤔
👀 Doing a self review
❔ Our contribution guidelines
🤏 Splitting feature into small PRs
➕ Adding a changeset
🧪 Providing/improving test coverage
🔐 Removing all sensitive information from the code and PR description
🚩 Using a feature flag to protect the release
👣 Providing comprehensive reproduction steps
📑 Providing or updating our documentation
🕛 Scheduling a pair reviewing session
📱 Providing mobile support
♿ Providing accessibility support
As an Author, before moving this PR from Draft to Open, I confirmed ✅