@VonOx I find the current build time for PRs is really long (almost 20-25 minutes), which makes multiple merges really long.
Currently, to merge 3 PRs, if I do it cleanly by merging each PR one by one to have a clean commit, it takes me 1h30, regardless of the content of the PRs and without counting the review time ^^
So I investigated, I found a first optimization lead: better parallelize the tasks.
For example, the « build front + Docker magic » task doesn’t actually need the « test-server » task (for a PR I mean, on master we want the tests to pass before doing a Docker build, but here little interest), so I wonder if we could remove the dependency?
Yes, I understand the logic, except that in the end it’s better to launch everything at the same time anyway, we’ll have the final report at the end.
By putting everything in parallel, we have a total test time of 12 minutes in general, it’s still a lot but it’s half as much It makes a big difference for me. 25 minutes of build, I feel completely unproductive, I spend my time waiting ^^
For information, I have updated the dependencies (mainly backend, a bit of frontend but as long as we don’t have the tests it’s hard), and I have added a dependency security audit step to Github action.
Well, this is getting complicated, the code coverage plugin used by Cypress is based on a version of Babel 7.x, but Preact-CLI 2.x forces the version of Babel to 6.x… I’m starting to sweat…
I’m fine with sharing the tasks, yes.
For the Cypress testing part, alone, I’m going to take a lot of time. I wonder if each developer should take the subject in hand to « train » and test at least their services.
Otherwise, yes, it would be good to start the Preact migration in parallel, and to note the critical points, to ensure that we cover them well with Cypress.
@contributors For information in case you haven’t seen it yet, @AlexTrovato is working on adding frontend tests, which will allow us to better monitor frontend regressions. We’re going to need everyone’s help to test each service
and I think we should merge gradually on this branch.
For each service tested, create a PR not towards master but towards this branch (if possible) and merge gradually.
I remain available, of course, in case of questions / blockages, the existing examples should be enough to complete the test suite, but it is very likely that new unanticipated cases will arise.
I am thinking, for example, of WebSocket, which I have not explored.
On my side, I keep my « migration preact 3 temporary » branch with coverage, I can run the coverage locally to alert contributors if a « big » part is missing.
We will refine / complete the coverage once the migration is validated, because on my temporary migration branch, many features are not working. @pierre-gilles I know your time is precious, so I am happy to take the « core » part in addition to my services, but I certainly will not be able to cover the gateway part.
If you want to participate to « train » yourself, we can share.
Just a bit of additional information.
For each « new » test, a JWT token needs to be generated via /login, and we quickly encounter this error « Status: 429 - Too Many Requests ».
We may need to add a configuration to disable this check on the server side.
This issue occurs when creating tests; for each new test, new run, we start from scratch (when running ALL tests, the token generated the first time is kept throughout).
It’s quite restrictive.
@pierre-gilles when you develop the tests, and when you save your new test, Cypress is reloaded (like the front with nodemon), and starts from scratch again.
In the case where you run all the tests at once, this token is indeed stored in Cypress’s environment variable,
but it’s really during the test development phase, where you progress « step by step, » that the problem occurs, because it is very difficult to write a good « graphical » test on the first try, and even if that’s the case, you need to be able to test each test after writing it, so refresh the Cypress environment, so generate a new token.
Well, after playing with it all morning, it doesn’t seem to be a real problem, but it was rather due to a bug in the « special » cypress-gladys (helpers) commands that I had set up to manage the token
So I managed to use WebSocket (to force/simulate an event).
Other info, following the verification of npm dependency vulnerabilities, the build no longer passes due to sequelize-cli and nyc: https://www.npmjs.com/advisories/1654.