Skip to content
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

Merged
merged 30 commits into from
Nov 8, 2021

Conversation

chrisbreiding
Copy link
Contributor

@chrisbreiding chrisbreiding commented Oct 13, 2021

User 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:

cypress open --browser does-not-exist

Screen Shot 2021-11-02 at 3 05 22 PM

PR Tasks

  • Have tests been added/updated?
  • Has the original issue or this PR been tagged with a release in ZenHub?
  • Has a PR for user-facing changes been opened in cypress-documentation?
  • Have API changes been updated in the type definitions?
  • Have new configuration options been added to the cypress.schema.json?

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Oct 13, 2021

Thanks for taking the time to open a PR!

@chrisbreiding chrisbreiding changed the base branch from develop to unified-desktop-gui October 13, 2021 15:00
@chrisbreiding chrisbreiding changed the title Support --browser cli option in Launchpad feat: Support --browser cli option in Launchpad Oct 13, 2021
Copy link
Contributor

@JessicaSachs JessicaSachs left a 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:

  1. Tests
  2. Approval from design

packages/launchpad/src/setup/OpenBrowserList.vue Outdated Show resolved Hide resolved
@chrisbreiding chrisbreiding marked this pull request as ready for review October 27, 2021 18:42
@chrisbreiding chrisbreiding requested a review from a team as a code owner October 27, 2021 18:42
@chrisbreiding chrisbreiding requested review from jennifer-shehane and removed request for a team October 27, 2021 18:42
@jennifer-shehane jennifer-shehane removed their request for review October 27, 2021 18:48
@@ -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) {
Copy link
Contributor Author

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.

Copy link
Contributor

@lmiller1990 lmiller1990 Nov 2, 2021

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

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.

Copy link
Contributor Author

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) => {
Copy link
Contributor Author

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.

@cypress
Copy link

cypress bot commented Oct 27, 2021



Test summary

18648 1 216 7Flakiness 3


Run details

Project cypress
Status Failed
Commit eafe525
Started Nov 8, 2021 3:52 PM
Ended Nov 8, 2021 4:05 PM
Duration 12:11 💡
OS Linux Debian - 10.9
Browser Multiple

View run in Cypress Dashboard ➡️


Failures

cypress/integration/commands/window_spec.js Failed
1 ... > throws when passed an invalid orientation on a preset

Flakiness

net_stubbing_spec.ts Flakiness
1 network stubbing > waiting and aliasing > can timeout waiting on a single request using "alias.request"
2 network stubbing > waiting and aliasing > can timeout incrementally waiting on requests
xhr_spec.js Flakiness
1 ... > no status when request isnt forced 404

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

@BlueWinds BlueWinds requested review from BlueWinds and removed request for BlueWinds November 2, 2021 16:01
@chrisbreiding
Copy link
Contributor Author

Got approval from Ryan on the warning design.

Copy link
Member

@tgriesser tgriesser left a 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.`
Copy link
Contributor

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.

Copy link
Contributor

@ryanjwilke ryanjwilke left a 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.

@tgriesser
Copy link
Member

Working on fixing the issue that's causing the failure here

@tgriesser
Copy link
Member

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.

@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

@tgriesser tgriesser merged commit a9902b2 into unified-desktop-gui Nov 8, 2021
@tgriesser tgriesser deleted the issue-18419-open-browser-flag branch November 8, 2021 16:06
tgriesser added a commit that referenced this pull request Nov 8, 2021
* unified-desktop-gui:
  feat: Support --browser cli option in Launchpad (#18473)
  feat: Add typings for new devServer config (#18797)
  feat(app): wire up cy.screenshot (#18768)
  feat: create specs ui (#18483)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for cypress open --browser <browser>
7 participants