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 |
||||||||||||||||||||||||||||||||||
tgriesser
left a comment
There was a problem hiding this comment.
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.
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.
I'll give this a try and see how it goes.
There was a problem hiding this comment.
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. |
| initializeEventManager(window.UnifiedRunner) | ||
|
|
||
| window.UnifiedRunner.MobX.runInAction(() => { | ||
| const store = initializeMobxStore(window.UnifiedRunner.config.testingType) |
There was a problem hiding this comment.
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.
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.
| throw err | ||
| } | ||
|
|
||
| getUrlsFromLegacyProjectBase (cfg: any) { |
There was a problem hiding this comment.
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. |
marktnoonan
left a comment
There was a problem hiding this comment.
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.
It looks like this function wasn't using config.namespace for anything, this is just cleanup?
| * either re-run a spec or update something in the App UI. | ||
| */ | ||
| configChange () { | ||
| this._emit('configChange') |
There was a problem hiding this comment.
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.
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.
ryanthemanuel
left a comment
There was a problem hiding this comment.
Looks good and works well. Nice work!

User facing changelog
Use subscriptions to update/respond correctly in app when
cypress.config.jsis updated. Now, if you updatecypress.config.json 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?