Point stability, dependency updates & code quality

@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?

I made a PR:

https://github.com/GladysAssistant/Gladys/pull/1104

The logic for me at the start was that there was no point in building the front end and Docker if the tests fail, hence the sequence.

As you wish!

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 :slight_smile: 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.

Cf

https://github.com/GladysAssistant/Gladys/commit/fecd2e751b267c3c6ab0beb443cb85aaf3ba5030

For Cypress, I think we have a good foundation to work with, registration and the Bluetooth page (real calls + mocks) are tested.

A question weighs on me: how to make these tests live in the PRs?

So I need to see if test coverage can be done with Cypress.

Do you mean reporting to Codecov?

Yes, I think we need code coverage like for the backend :slight_smile:

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…

To address this issue, I performed a « quick and temporary » migration from preact-cli to v3, and now I have a nice report

(screenshot cropped)

I think we will therefore need to

  1. do as much « eye » coverage with cypress
  2. [mergeable tests (with ci)]
  3. perform the preact migration (not so simple)
  4. enable cypress coverage
  5. complete the cypress test suite
  6. when the coverage is satisfactory, merge the preact migration and the coverage

ouch!! the preact migration is going to be tough, I’ve tried several times I sweated, it’s really not obvious :stuck_out_tongue:

Otherwise, in the idea it’s fine with me, do you want help with the preact migration? if you’re stuck on something let us know :slight_smile:

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.

I agree!

@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 :slight_smile:

How do we organize?

We should already start from my version

https://github.com/GladysAssistant/Gladys/pull/1086

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.

Is it possible to check the NODE_ENV variable and disable the verification of the number of requests made if NODE_ENV=development?

Why don’t you get a jwt just at the start of the tests (a kind of before() like with mocha I don’t know if it exists?)

It seems heavy to do a login for each test!

I think it would be good if I trained too! I would come as reinforcement once I’ve finished the short subjects (zigbee2mqtt and co)

@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 :slight_smile:

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.

To track the progress of the Cypress coverage, I created a GitHub project.

https://github.com/orgs/GladysAssistant/projects/4