fix: cypress test for GitHub login do not try to revalidate the app

[gentlementlegen]

This PR aims to solve issues encountered when running Cypress for the login test step.

The main issue is that GitHub rate limits users on how many times they can hit the login endpoint. If too many tests are run, the redirect doesn't happen on login and instead asks the user to revalidate the app. A case was made for this workflow, but after testing more thoroughly I saw that GitHub has a hard limit as shown in the screenshot

I don't think there is any workaround on this, since we have no control other those limits. It is not possible to fake an OAuth except if we run all locally (very unlikely scenario). I think this would not happen often if users try locally with their own account, since the Cypress tests will run once in a while and not every 2 seconds. So this scenario should (hopefully) be unlikely to happen. Still, few measures were taken:

• enabling Cypress videos to help debugging
• add an explicit comment and the necessary code to solve the issue when the rate limit is exceeded
• updated Cypress to the latest version
• changed Cypress trigger to be pushes to the development branch as I know @rndquu is eager to remove the pull_request_target events

[ubiquity-os-deployer]

bca9230

71845fd

37ae558

d413ea3

[0x4007]

I don't think there is any workaround on this, since we have no control other those limits

If you want to over engineer this we can use free proxies like from spys.one

[gentlementlegen]

I don't think there is any workaround on this, since we have no control other those limits

If you want to over engineer this we can use free proxies like from spys.one

I am not even sure it would fix the problem since it is based on the amounts of logins you do with a specific account, it maybe does not even depend on an IP address, but could be tried.

[0x4007]

I don't think there is any workaround on this, since we have no control other those limits

If you want to over engineer this we can use free proxies like from spys.one

I am not even sure it would fix the problem since it is based on the amounts of logins you do with a specific account, it maybe does not even depend on an IP address, but could be tried.

Is it worth it to rotate between fake accounts? It's pretty easy to make new GitHub accounts.

[gentlementlegen]

I don't think there is any workaround on this, since we have no control other those limits

If you want to over engineer this we can use free proxies like from spys.one

I am not even sure it would fix the problem since it is based on the amounts of logins you do with a specific account, it maybe does not even depend on an IP address, but could be tried.

Is it worth it to rotate between fake accounts? It's pretty easy to make new GitHub accounts.

I also thought about this. Probably can be achieved, it would require creating a new email each test with something like https://ethereal.email/ to do so. Just thought it'd be overkill at least for now since this should not manifest often.

[0x4007]

With Cloudflare its easy to make catch-all emails. This way we can have a single domain and then dynamically enter in any email address we want, while all of the messages forwarding to a single inbox.

[gentlementlegen]

Sounds good. But we should make the whole workflow of registering accounts, which includes validating email etc. Might want a dedicated task for this. That PR should be enough of a fix for the current problem.

[0x4007]

we should make the whole workflow of registering accounts

We just care about GitHub accounts not emails though. I don't think we need to make a big project out of it?

For identities in the DevPool we just need GitHub accounts and those associated with wallet addresses.

[gentlementlegen]

But I am confused how can you make GitHub accounts without email? Or maybe you meant having a pool of emails and rotate between them?

[0x4007]

Or maybe you meant having a pool of emails and rotate between them?

Yes but that's interesting if you're proposing to generate random emails and then actually logging into some shared inbox and clicking the link. Its theoretically possible, especially if that inbox forwards emails to some service that we can easily access the emails from some restful API.

There are also some automations for Gmail that can automatically click on registration links etc. I used to have some old AppsScript that would automatically unsubscribe from newsletters by clicking any links that regex match unsubscribe etc

[gentlementlegen]

Or maybe you meant having a pool of emails and rotate between them?

Yes but that's interesting if you're proposing to generate random emails and then actually logging into some shared inbox and clicking the link. Its theoretically possible, especially if that inbox forwards emails to some service that we can easily access the emails from some restful API.

There are also some automations for Gmail that can automatically click on registration links etc. I used to have some old AppsScript that would automatically unsubscribe from newsletters by clicking any links that regex match unsubscribe etc

Nodemailer is also a good tool for that, used it before for similar purposes. I have to look closer to what Cloudflare can offer on that regard, maybe that's our best solution. We might wanna merge that for now to fix the current test, and dedicate a task for more advanced testing!

[0x4007]

You can merge when you think this is good to go.