-
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
fix: subscribe to changes in cypress.config.js in app #21160
Conversation
Thanks for taking the time to open a PR!
|
Test summaryRun details
View run in Cypress Dashboard ➡️ 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 |
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 are actually going to also want to show the loading spinner when the background process is refreshing, @marktnoonan was looking into that as a separate ticket
// if the `config` changed, we want to reload the entire | ||
// page and re-execute the current test with the latest config | ||
// values | ||
// subscriptions trigger on the initial page load, | ||
// so we do not want to trigger `window.location.reload` on the | ||
// first load, or we get stuck in an infinite loop. |
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.
What if we send the config values in the subscription as a new field with a JSON
payload, and then set them on window.__CYPRESS_CONFIG__
?
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 give this a try and see how it goes.
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.
Your idea is quite a bit better in terms of reliability. I found something troubling; the config we source in data-context
was missing some dynamic values like the proxyUrl
. See those here: https://github.com/cypress-io/cypress/pull/21160/files#diff-06b7fcb589558cace004423a0085796fa17cfb870f200c97b66105c7400c69d6R45-R56
For now I patched it in, but we need to continue to aggressively triage the config problem we've got and find a single way to manage and source it.
I'd say the next step would be a solid refactor of project-base
, open-project
and server-{base,e2e,ct}
and the surrounding area, but this is quite high risk, so not sure we should do that right now. I might start a tech brief where we can gather our thoughts about this.
Yeah I was going to either write that up as a ticket or add it as a part of #21157 |
@tgriesser @marktnoonan I agree we should show a spinner here too, is there a mock for this? Should it be included in this ticket? It could be implemented separately. |
// window.UnifiedRunner exists now, since the Webpack bundle with | ||
// the UnifiedRunner namespace was injected by `injectBundle`. | ||
initializeEventManager(window.UnifiedRunner) | ||
|
||
window.UnifiedRunner.MobX.runInAction(() => { | ||
const store = initializeMobxStore(window.UnifiedRunner.config.testingType) |
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.
We can kill off most of window.UnifiedRunner
soon
0bb4e41
to
c626a22
Compare
} | ||
|
||
if (!initialLoad && specStore.activeSpec) { | ||
try { |
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 super ideal, since we don't know that eventManager will absolute exist here (potential race condition, you changed cypress.config.js
while the spec is still "Spec is loading...", so I just did a try/catch.
@@ -41,8 +42,32 @@ export class HtmlDataSource { | |||
throw err | |||
} | |||
|
|||
getUrlsFromLegacyProjectBase (cfg: 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.
The config we get in the data-context doesn't have some of these important keys. They are dynamically added later, for example the port
will only be added once the CT dev server has started.
We'll need to find a way to better manage the config in general, but this fixes the problem for now and links the "legacy" part of config in project-base
and server-{ct,e2e}
with the newer data-context stuff.
In testing I was able to reach one state surprised me a lot - no error shown and on refresh I saw this: Turns out I saved, or the editor autosaved, with a I also hit a broken state in CT but I think that makes sense based on the description here, I added a question: https://cypress-io.atlassian.net/browse/UNIFY-1236 Haven't finished reviewing the code yet, just wanted to share update. |
Found a potential issue when switching testing types, shown here: https://www.loom.com/share/79e5288cc9ea49bd8d88d454865e0dce Not sure how to recreate it, just captured what I could. |
Thanks for the update @marktnoonan, looks like so far it's okay except for that weird bug you found in loom - thanks for capturing that. I'm not sure if I can reproduce, but I'll give it a try. If we can reproduce, it could be a separate PR? I can see this blowing out if we try to fix any and all config errors here - my main goal was to hook up subscriptions. |
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.
All looks good and works well in e2e and on settings page, happy to create a follow up issue for my last comment, though since it is testing-type related, I will hold off until we have the config reloading not breaking CT, since that's a possible confounder.
|
||
store.updateDimensions(config.viewportWidth, config.viewportHeight) | ||
}) | ||
|
||
window.UnifiedRunner.MobX.runInAction(() => setupRunner(config.namespace)) |
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.
It looks like this function wasn't using config.namespace
for anything, this is just cleanup?
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.
Yep, unused.
* either re-run a spec or update something in the App UI. | ||
*/ | ||
configChange () { | ||
this._emit('configChange') |
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.
Do we envision that this can eventually negate the need for some of the toApp
and toLaunchpad
calls elsewhere?
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.
Good question - for now I'm guessing we want to respond to any config changes in both. I can't think of any reason to selectively only update only app
or only launchpad
at this point.
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 and works well. Nice work!
User facing changelog
Use subscriptions to update/respond correctly in app when
cypress.config.js
is updated. Now, if you updatecypress.config.js
on the runner page (eg changeviewportHeight
) it will re-execute the spec with the new config.It can feel a bit unresponsive, since we re-run the child process to get the latest config. We will add an overlay with "Loading..." to give the user immediate feedback that we are reloading, that'll be part of another PR, see this comment.
Additional details
I also found a bug where CT fails to reconnect to the dev server after you change
cypress.config.js
. https://cypress-io.atlassian.net/browse/UNIFY-1675. It's outside the scope of this ticket, though, but we should look into this as a fast follow up.How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?cypress.schema.json
?