-
Notifications
You must be signed in to change notification settings - Fork 17
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
[CSR-791] cypress-cloud is not compatible with cypress 13.x #179
Comments
The fix is in progress |
Please check out the upgrade guide: https://currents.dev/readme/integration-with-cypress/cypress-cloud/migration-to-cypress-13 |
I just tested the upgrade to cypress-cloud beta and tests are no longer reported as failing, see https://jenkins.softwareheritage.org/blue/organizations/jenkins/DWAPPS%2Fgitlab-builds/detail/gitlab-builds/302/pipeline/89/. There is still the error about screenshots that appears after each test suite though but if you do not use that cypress feature it is not critical for running the tests. |
I too am having issues with the latest build
Hacking in a bit of debugging, it seems that EDIT: In |
Thanks @anlambert and @richardmward, working on the fixes for those issues |
For us, after updating everything to the latest version we got the following error, and the specs are not executed:
Versions:
|
@estefafdez thanks for reporting - will keep cypress-debugger issue separated @Roemer, @anlambert and @richardmward please check out |
That has sorted my issue. Thank you. |
@agoldis the debugger issue is already reported there currents-dev/cypress-debugger#59 The problem is that you can run the tests in Cy13 but you can't see the results in sorry cypress, Something seems to be missing as well. |
Anyone else experiencing tests just getting stuck and never finishing? I'm using |
@agoldis I just upgraded to beta 3 and executed the cypress tests of the project I am working on, all good from my side and it indeed fixes the screenshots processing bug, see https://jenkins.softwareheritage.org/blue/organizations/jenkins/DWAPPS%2Fgitlab-builds/detail/gitlab-builds/306/pipeline/88. Nevertheless, I only use |
@anlambert what did you see on the cypress dashboard when the run is finished? did you see the results there? |
@estefafdez @richardmward Please check out Also, the corrupted runs could have incompatible data, they should be removed from the DB. |
@andreiho we need more data to explore the case - the debug logs would help |
@estefafdez regarding the sorry-cypress dashboard feature, I bumped cypress-cloud to |
@andreiho I also experience this with One thing I also noticed is that whenever I check the here's additional info: |
@bilarallen thanks for elaborating on the issue. If that is reproducible, please share a standalone example or and debug logs (https://currents.dev/readme/integration-with-cypress/troubleshooting) |
Hi @agoldis This can only be replicated when running a test via cypress runner through
Steps to replicate when using cypress runner and importing
|
@agoldis @bilarallen : I'm experiencing the same issue with |
Ok, for me is finally working with:
@agoldis thanks! |
@agoldis @bilarallen I've been trying to create a reproducible example, but can't manage to. It appears to be related to some of the custom behaviour we have implemented to deal with some technicalities in our application. But I can't quite explain how importing the cypress-cloud code results in the tests hanging and cypress freezing completely. I'll try to give a bit more context into our situation. We have a few custom commands which we run on most tests, in order to perform certain actions before proceeding with the test. In this case, the Now I've tried changing different things in these commands in an attempt to maybe fix some issues, but I can't quite get to the bottom of it, particularly why importing cypress-cloud ends up manifesting this way. It does however work if I simply just never call the This could of course be sub-optimal code on our part, but why would it only manifest itself this way while cypress-cloud is imported? I've tried looking at your Our custom commandsexport const navigateTo = (
routePath = '/',
options: { isLoggedIn?: boolean; force?: boolean } = {},
): void => {
const url = new URL(`${Cypress.env('BASE_URL')}${routePath}`);
const { force = false, isLoggedIn = true } = options;
cy.url().then((href) => {
if (force || href !== url.href) {
cy.visit(url.href);
cy.get('body').should('not.have.class', 'loading');
if (isLoggedIn) {
cy.get('#alerts-holder', { timeout: 20000 }).should('exist');
cy.clickNotificationButton();
}
}
});
};
export const clickNotificationButton = (
buttonText?: string,
): Cypress.Chainable<JQuery<HTMLElement>> => {
return cy
.get('#alerts-holder')
.as('alerts')
.then(($aw) => {
if (buttonText) {
cy.get('@alerts')
.contains(button, buttonText)
.as('button')
.then(() => {
cy.get('@button').click();
});
} else if ($aw.find('[aria-label="close"]').length) {
cy.safeClick(
() => cy.get('#alerts-holder button[aria-label="close"]'),
{
multiple: true,
},
);
}
});
};
export const safeClick = (
cySelectorFn: () => Cypress.Chainable<JQuery<HTMLElement>>,
clickOpts?: Partial<Cypress.ClickOptions>,
): Cypress.Chainable<JQuery<HTMLElement>> => {
return cy
.waitUntil(
() => {
return cySelectorFn()
.as('clickable')
.wait(10) // https://github.com/cypress-io/cypress/issues/7306
.then(($el) => Cypress.dom.isAttached($el));
},
{ timeout: 1000, interval: 10 },
)
.get('@clickable')
.click(clickOpts);
}; |
Okay after poking around a bit more, I think I may have found the culprit. You can probably disregard most of what I said in my previous message, although I still think there's some relation between the how tests are written, and what happens further down. The cy.task(
`currents:test:after:run`,
safeStringify({
...test,
fullTitle: test.fullTitle()
}),
{
log: false
}
); |
@andreiho thanks a lot for the detailed response. Any chance you can share the test / sample with me somehow? Another approach would be to put a breakpoint right before stringifying the result and make sure that the function returns. |
@agoldis I did try a breakpoint and calling the stringify function in the console, and it never returns, it just hangs indefinitely and the browser becomes virtually unusable, requiring force quit. Haven't been able to put something useful together to share, as it seems somewhat related to some of the more complex orchestration of our application, with large number of requests made on load and various mocks and intercepts. The test itself is as simple as it gets, I tried running it on a dummy HTML webpage and everything works fine, which makes me think it's something else in the background that is part of the test object which the stringifier doesn't like. I might try manually inspecting that test object before/after commenting out some of the code I previously mentioned which seems to unblock the tests, and see what the differences are. |
@andreiho would you be able to join a quick support call? |
Hi, @agoldis I tried to use the Also, there's one thing I noticed in terminal when running the test in cypress GUI (e2e) see my cypress config file particularly lines 43 and 46 |
Cypress 13 got us this error tonight:
it's working with cypress 12.17.4 but not working again with cypress 13 :( |
@estefafdez |
Same as @estefafdez |
Right now, downgrade to cypress 12 (latest version) and wait until the currents teams think about a solution :( |
This will be hard one, i guess... |
Same on our side... |
Same issue from my side, regardless Curiously, I can run the tests locally without any issue:
|
[cypress-cloud] Could not get cypress attempt error details |
same here, I can run in my local successfully, but in lambda environment(Lambda function from a container image) got the 3rd party error. I also tried to run the docker image in my local with |
Based on my experimental guesses, the logic for detection is in the cypress binary and does not require an internet connection, and there may be two points of detection:
|
I am a bit confused. Cypress launched the Edit: According to Cypress, it should work with a valid Cypress Connector Gateway license, I will give it a try next week. |
We are getting this error while running cypress in Jenkins pipeline - "We've detected that you're using a 3rd party library that is not supported by Cypress: cypress-cloud below is my configuration: "cypress": "^13.3.0", followed the migration document and made the changes accordingly - https://currents.dev/readme/integration-with-cypress/cypress-cloud/migration-to-cypress-13 |
The Cypress team is already investigating and working on a fix cypress-io/cypress#27924 it seems other libraries that do not make test recordings were also affected. 🤞 that this will solve the issue with currents, if not where do we go from here? 🥲 |
Seems like cypress is not going to fix this. Ticket ist closed and I still get the error message after clearing the runner cache like described in the ticket |
Hey everyone, we published the response with more details about the recent blocking, including the technical analysis. We need to change our approach because they will keep implementing new blockings. It requires careful planning and more time. Thanks for your patience and support! |
According to Cypress, they want to get this working for paying customers (like we are with the |
|
Would forking Cypress be a viable solution to this? |
I made a fork of cypress-cloud and renamed everything possible. And it worked for.version 13.3.0. |
Could you share how to do it please? |
https://www.npmjs.com/package/@krivega/cc This is a temporary solution, now I am afraid that they will block it too) |
so it's dead end of 3rd party self hosted cypress monitor ? 😭 |
@GeuntaBuwono you can still use older versions of cypress https://currents.dev/readme/integration-with-cypress/alternative-cypress-binaries |
cypress has already released stable version 14.0.0.. so isn't it time to support the latest version cypress 13 stably? |
Before opening, please confirm:
Environment information
Describe the bug
Due to this cypress commit that introduces some breaking API changes in cypress 13.x, I noticed two issues when using cypress-cloud with it:
See sample cypress-cloud output put below:
After reading cypress-cloud code, it seems that issue can be fixed using the following diff:
Once the fix above applied, there is an error when cypress-cloud attempts to process test screenshots, see output below:
The fix for this one is not straightforward to me.
Expected behavior
cypress 13.x should be supported.
Command and Setup
Just run any cypress-cloud session with cypress 13.x and the reported errors will show up.
Full log and debug output
cypress_cloud_debug_logs.txt
The text was updated successfully, but these errors were encountered: