-
Notifications
You must be signed in to change notification settings - Fork 3.4k
feat: IATR-M0 Page Header #24722
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: IATR-M0 Page Header #24722
Conversation
Test summaryRun details
View run in Cypress Dashboard ➡️ Failures
Flakiness
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 |
||||||||||||||||||||||||||||||||||||||||||
warrensplayer
left a comment
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.
Still looking through details, but wanted to get this feedback to you.
| ] | ||
| const acc: status[] = [] | ||
| if (props.order) { |
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.
Should the order even be configurable? The results this component displays should be consistent across features, otherwise it becomes confusing.
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 is an attempt to make the ResultCounts.vue component more generic. In its current implementation, the status can only appear in a certain order i.e. skipped, pending, passed, failed. You can see this generic component in the Runs tab for the app.
Based on the design requirements for this issue, the order of these "statuses" is different. Hence, instead of building a whole new component we can utilize ResultCounts.vue and just pass in a different order incase in the future the order of "statuses" is different.
As for the component being consistent, I agree with that. I don't see why the "status" order should differ across pages. However this has been added to meet the design requirements
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 would sync back with design regarding this, this result of this list (in my mind) should be consistent regardless of if you're looking at the runs page or the debug page
lmiller1990
left a comment
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.
Sure looks pretty, left some comments
| </script> | ||
| <style scoped> | ||
| ul:nth-child(2) li:not(:first-child)::before { |
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.
Woah, this is specific. I think this CSS could break easily.
I'm not sure what it does, but can we use a class or id or something that isn't tied to a specific DOM structure?
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 adds the " . " after each component in the bottom section of the UI. That way we don't manually have to add " . " in our template. It is similar to styling here
| <div | ||
| class="text-red-400 font-semibold text-sm flex items-center border-r-1px px-2" | ||
| > | ||
| <component |
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.
Why not just
<FailedSolidIcon
class=...
data-cy=...
/><component> is good for dynamic content - but this isn't. (Could be missing something).
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 will not always be a FailedSolidIcon. In future iterations, this could be a PassedIcon or hold other statuses hence the <component>
| import type { DebugResultsFragment } from '../generated/graphql' | ||
| import { gql } from '@urql/core' | ||
| import FailedSolidIcon from '~icons/cy/status-failed-solid_x24.svg' | ||
| import ResultCounts from '@packages/frontend-shared/src/components/ResultCounts.vue' |
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.
Curious what the team things but this seems like it's not really a good candidate for frontend-shared. It doesn't seem like something we will use in other packages (like launchpad).
Thoughts? cc @marktnoonan, we had a brief discussion around this.
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.
@lmiller1990 The ResultsCounts is an existing component that was just getting reused here with a minor addition. I do agree that it is only used in app so does not need to be in frontend-shared, but we can refactor that another time.
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.
Sounds good to me
warrensplayer
left a comment
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.
Just one minor nit-pick
| import type { DebugResultsFragment } from '../generated/graphql' | ||
| import { gql } from '@urql/core' | ||
| import FailedSolidIcon from '~icons/cy/status-failed-solid_x24.svg' | ||
| import ResultCounts from '@packages/frontend-shared/src/components/ResultCounts.vue' |
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.
@lmiller1990 The ResultsCounts is an existing component that was just getting reused here with a minor addition. I do agree that it is only used in app so does not need to be in frontend-shared, but we can refactor that another time.
lmiller1990
left a comment
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 good, left one last comment but not a blocker.
| import type { DebugResultsFragment } from '../generated/graphql' | ||
| import { gql } from '@urql/core' | ||
| import FailedSolidIcon from '~icons/cy/status-failed-solid_x24.svg' | ||
| import ResultCounts from '@packages/frontend-shared/src/components/ResultCounts.vue' |
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.
Sounds good to me
|
Updating the feature branch and merging it in here, should fix CI. I'll merge once this is green. |
|
Looks like we have a CI failure - re-ran but still failing, want to take a look @amehta265? https://app.circleci.com/pipelines/github/cypress-io/cypress/46041/workflows/a86994bb-0f07-454a-bfaf-60c6048476a0/jobs/1936007/tests#failed-test-0 |
|
Actually @amehta265 it might be flake, see #24575 |
…press-io/cypress into ankit/IATR-M0-debugPageHeader Merging with remote branch
User facing changelog
This component is the header of the new debug page that represents the chosen run and its metadata.
The design for this page can be found here
Additional details
DebugPageHeadercontains metadata related to a user's test. In order to render the status of the test (i.e. number of passed, failed, skipped, pending tests) I have also created another componentDebugResults.DebugResultsutilizes an already existing componentResultCountsto render the UI for this section. Changes have beenResultCounts.vueto accommodate for a change in theorderof statuses shown as per design requirements.debugPageHeaderacceptsgqlvalues as a prop. In case these props are not passed to the component it will render default values.commitsAhead()are merely placeholders and will be implemented later on. Furthermore thegqlquery will potentially change in the futureSteps to test
This issue has 3 component tests. Checkout to this branch to run the tests
Both
DebugPageHeader.vueandDebugResults.vueexist in thepackages/app/folder. To run these tests:packages/appyarn devDebugPageHeader.cy.tsxandDebugResults.cy.tsxTo test
ResultsCounts.vueyarn cypress:openfrontend-sharedas a projectResultCounts.cy.tsxHow has the user experience changed?
PR Tasks
cypress-documentation?type definitions?