-
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: Add support for optional env key to browser launch options #23624
Conversation
Thanks for taking the time to open a PR!
|
@emilyrohrbough - Finally got back to this! Let me know what y'all think when you get to it. It'll go a long way to improve the DX for replay.io users integrating with cypress.io! |
@ryanjduffy Thank you so much! I will add this to my list to review and get back to you shortly. Hopefully by end of day today, if not by EOD tomorrow! |
packages/launcher/lib/browsers.ts
Outdated
@@ -181,7 +182,9 @@ export function launch ( | |||
|
|||
// allow setting default env vars such as MOZ_HEADLESS_WIDTH | |||
// but only if it's not already set by the environment | |||
const env = Object.assign({}, defaultBrowserEnv, process.env) | |||
const env = Object.assign({}, defaultBrowserEnv, browser.env, launchOptionsEnv, process.env) |
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.
@ryanjduffy It looks like this change is doing more than accepting env values form the launchOptions. I wouldn't expect envs set on the found browser to be used in the node process that starts the browser. In the previous PR you had opened, you had linked to a few code snipped in reply & you're plugin. Where are these ENV values actually getting applied on the browser obj?
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.
Not sure I follow but I'll share some context here in hopes that clarifies!
Here's the current code in our plugin. It's of course not setting env variables yet because it can't!
The eventual implementation after this landed would be:
on("before:browser:launch", (browser, launchOptions) => {
selectedBrowser = browser.family;
reporter.onTestSuiteBegin(undefined, "CYPRESS_REPLAY_METADATA");
launchOptions.env = {
RECORD_ALL_CONTENT: 1,
RECORD_REPLAY_METADATA_FILE: '/path/to/file.json'
};
return launchOptions;
});
The goal here being that we need to configure the replay browser with RECORD_ALL_CONTENT
to instruct the firefox fork to record everything (unlike the desktop experience in which the user clicks the Rec button) and where to find metadata for the recording which is how we link up the recording with the test result.
This is all happening from the plugin because that's the point at which we have the test context to add the metadata. IIRC, I also didn't find another way to set an environment variables for the launcher node process beyond requiring the user to set them before invoking cypress.
Hope that helps! Happy to have a quick video call to chat if that's useful too.
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.
Also, i'm in the cypress community discord as ryanjduffy if you want to chat there!
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.
@ryanjduffy This is great insights! Thank you!
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.
Explanation makes sense for why we pass launchOptionsEnv
(which will contain the REPLAY_
variables) but why did we add browser.env
here, too?
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 like browsers.env
was just cruft from my prior impl. @emilyrohrbough 's suggestions to drop those two diffs should do the trick!
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.
Is there a good way to test this manually? Eg - should we set up Replay locally? Considering this is a new feature, after all, I think we probably should do some testing on our end before we review + merge it.
a29d202
to
7b637df
Compare
Force pushed a fresh commit to rebase on |
Definitely! I'm walking through the steps myself now to verify it all one more time. Our Cypress instructions cover most of it. I can push an experimental version of our plugin that uses this feature so others can try it as well. |
Manual testing steps:
|
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 needs a docs PR, this file should be edited: https://github.com/cypress-io/cypress-documentation/blob/master/content/api/plugins/browser-launch-api.md
packages/launcher/lib/browsers.ts
Outdated
@@ -166,6 +166,7 @@ export function launch ( | |||
debuggingPort: number, | |||
args: string[] = [], | |||
defaultBrowserEnv = {}, | |||
launchOptionsEnv = {}, |
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 too many parameters for this function, can you either remove the need for this parameter or move the parameters for .launch
into an options
object?
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'll collapse the two env members into one.
@@ -5480,6 +5480,7 @@ declare namespace Cypress { | |||
extensions: string[] | |||
preferences: { [key: string]: any } | |||
args: string[] | |||
env: { [key: string]: any } |
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 essentially a no-op in Electron, should we add an error or warning if someone sets .env with Electron?
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 noticed that args
seems to be the same so I've added a warning for both of those. Let me know if I've misread and args
is used or if there's a different way that is preferred for warning.
|
@ryanjduffy works great for me, I followed the steps and got it:
Left a quick comment on the docs PR, I'll wait for @flotwig to loop back and approve this PR, but looks good to me. |
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.
Sorry for the delay, one last question!
if (launchOptions.args.length > 0) options.push('args') | ||
|
||
if (options.length > 0) { | ||
errors.warning('BROWSER_UNSUPPORTED_LAUNCH_OPTION', 'electron', options) |
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.
@ryanjduffy sorry last comment here before approval... how can I actually pass something to this? I want to verify this error actually shows up, but I couldn't figure out how.
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.
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.
Changes look good! I reran CI and we have a few build failures, lmk if you need help fixing those up. A few are snapshot related, but we did recently add webkit support so looks like we need to make some tweaks there.
Looks like it. Fixing up now |
87e8fbe
to
ecbdfe1
Compare
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.
Pushed a commit ensuring the warning shows up correctly 👍
Seems I broke something when I pushed a commit, reverting + fixing... |
Looks like the
should do the trick. |
Looks like a few more needed updating, I ran + pushed. 🤞 |
Looks like we need to tweak one more system-test onRun: (exec, browser) => {
if (browser === 'electron') {
return exec({ originalTitle: `deprecated before:browser:launch args / using non-deprecated API - no warning - [electron]` })
}
return exec({ originalTitle: `deprecated before:browser:launch args / using non-deprecated API - no warning - [firefox,chromium]` })
}, I'd push but my local is a bit borked. Could you add those changes and run |
LGTM! |
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
User facing changelog
n/a
Additional details
Related PR: #22250
In building out support to integrate replay with cypress, I discovered there isn't a way to set environment variables for the browser without putting the onus on the end user. Further, since the browser launch seems to happen in a different process than the plugin, I couldn't inject those values into
process.env
and have them picked up by the existing logic.This adds support for an optional
env
key on the launch options passed tobefore:browser:launch
which is then merged with thedefaultBrowserEnv
andprocess.env
. I placed it between those two so the default browser family config (defaultBrowserEnv
) would be overwritten by browser instance config (browser.env
) which would be overwritten by the currentprocess.env
.Steps to test
before:browser:launch
handler insetupNodeEvents
to add an env variableHow has the user experience changed?
PR Tasks
cypress-documentation
? Update browser launch options for env key cypress-documentation#4730type definitions
?