-
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: Support --browser cli option in Launchpad #18473
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.
Tiny one-liner Vue change. Code looks good. I haven't manually tested this.
Still need:
- Tests
- Approval from design
@@ -232,10 +232,6 @@ export const mutation = mutationType({ | |||
t.liveMutation('launchOpenProject', { | |||
description: 'Launches project from open_project global singleton', | |||
resolve: async (_, args, ctx) => { | |||
if (!ctx.wizardData.chosenTestingType) { |
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 check is now done in ctx.actions.project.launchProject
.
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 probably just want to return null
here - @tgriesser mentioned the convention when a mutation "fails" was just to return null
if I recall correctly.
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.
Done
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.
For Query fields "failing", you'd want to return null, I think for mutations that are called in an invalid way it probably makes sense to throw b/c you have better control of the order of execution of those.
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.
So in this particular case, it should throw, right?
}) | ||
} | ||
|
||
const isValidPathToBrowser = (str) => { |
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 all moved here from browser/index.js
so that it will play nicely with @packages/data-context
, which is stricter about TypeScript, but none of it is fundamentally changed. The above function needed to be moved out of the object below so it can be referenced by these functions.
Test summaryRun details
View run in Cypress Dashboard ➡️ Failures
FlakinessThis 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 |
Got approval from Ryan on the warning design. |
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.
Haven't looked into why the test is failing, but feel free to skip / add a TODO if you're having issues and I can address as part of #18776 which will look to cleanup the overall flow of testing CLI flags
browser = (await this.ctx._apis.appApi.ensureAndGetByNameOrPath(browserNameOrPath)) as FoundBrowser | undefined | ||
} catch (err: unknown?) { | ||
this.ctx.debug('Error getting browser by name or path (%s): %s', browserNameOrPath, err?.stack || err) | ||
this.ctx.coreData.wizard.browserErrorMessage = `The browser '${browserNameOrPath}' was not found on your system or is not supported by Cypress. Choose a browser below.` |
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.
My only concern with this is that "Choose a browser below" feels pretty repetitive given the title of the page is essentially this as well.
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 left one comment that would be nice to address before releasing this, but if others disagree, then there's no need to block this PR over that from my perspective.
Working on fixing the issue that's causing the failure here |
@ryanjwilke Merging this PR to unblock separate work that's dependent on this landing to cleanup our testing Probably worth making a note of your feedback and updating the wording here during our phase of testing/refining |
cypress open --browser <browser>
#18419User facing changelog
cypress open --browser <browser>
will automatically select the browser.Additional details
Displays this when the browser can't be found or isn't supported:
PR Tasks
cypress-documentation
?type definitions
?cypress.schema.json
?