Skip to content
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

chore: allure test reporting #1668

Merged
merged 24 commits into from
Oct 23, 2023
Merged

chore: allure test reporting #1668

merged 24 commits into from
Oct 23, 2023

Conversation

fbarbu15
Copy link
Collaborator

@fbarbu15 fbarbu15 commented Oct 16, 2023

Problem

Test results were hard to follow in the console output.
Also we had no history to check flaky tests

Solution

Added allure test reports that are deployed with github pages: https://waku-org.github.io/allure-jswaku/5676/#

Notes

  • Moved mocha config from json to js so it supports conditional changes

@github-actions
Copy link

github-actions bot commented Oct 16, 2023

size-limit report 📦

Path Size Loading time (3g) Running time (snapdragon) Total time
Waku core 83.85 KB (0%) 1.7 s (0%) 2.7 s (+20.19% 🔺) 4.3 s
Waku Simple Light Node 264.2 KB (0%) 5.3 s (0%) 6.4 s (+31.45% 🔺) 11.7 s
ECIES encryption 79.46 KB (0%) 1.6 s (0%) 2.9 s (-23.63% 🔽) 4.5 s
Symmetric encryption 79.47 KB (0%) 1.6 s (0%) 3.6 s (+17.84% 🔺) 5.2 s
DNS discovery 111.22 KB (0%) 2.3 s (0%) 5.4 s (-3.73% 🔽) 7.6 s
Privacy preserving protocols 131.77 KB (0%) 2.7 s (0%) 3.5 s (-16.41% 🔽) 6.1 s
Light protocols 81.57 KB (0%) 1.7 s (0%) 2.8 s (+16.63% 🔺) 4.5 s
History retrieval protocols 80.54 KB (0%) 1.7 s (0%) 1.6 s (-17.01% 🔽) 3.2 s
Deterministic Message Hashing 5.65 KB (0%) 113 ms (0%) 367 ms (-4.44% 🔽) 480 ms

@fbarbu15 fbarbu15 added the E:End-to-end testing See https://github.com/waku-org/pm/issues/34 for details label Oct 17, 2023
@fbarbu15 fbarbu15 marked this pull request as ready for review October 19, 2023 16:32
@fbarbu15 fbarbu15 requested a review from a team as a code owner October 19, 2023 16:32
Copy link
Collaborator

@danisharora099 danisharora099 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need to create a separate mocharc for all packages?

@fbarbu15
Copy link
Collaborator Author

why do we need to create a separate mocharc for all packages?

@danisharora099
Well I just replaced .mocharc.json to .mocharc.cjs, so all the packages that contained tests already had their own mocharc.json
I guess the reason for this is that each package can be considered as a standalone project with it's own config (tsconfig, eslint, typedoc etc) and scripts (package.json).
The advantage with this is that we can run all tests(from all packages) from the root of the project or cd to a specific package and run the tests in isolation. We can also have different configs for each package.

@@ -6,6 +6,7 @@ import { getPublicKey } from "./crypto/index.js";
import { createDecoder, createEncoder } from "./ecies.js";

describe("Ecies Encryption", function () {
this.timeout(20000);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this PR, since I had to replace the mocha config in all packages, I activated parallel runs in the CI for all packages.
And while parallel runs, test are taking longer to execute.
I saw that tests failing in the CI with the test timing out with the default 2000 ms timeout so I've increased it similar with other tests.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these timeouts related to nwaku-jswaku communication or it's random?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that it's related to either how mocha implements concurrency or by the fact that because we run multiple containers at the same time when running tests in parallel, things start to slow down.
Github actions machine is also pretty low on resources so it's kinda expected to see such timeouts when running tests in parallel.
Those tests run in less than 1 second in serial mode that's why I don't think it's related to waku at all

if: always() && env.ALLURE_REPORTS == 'true'
run: node ci/mergeAllureResults.cjs

- name: Get allure history
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since reports are in the separate repo now - do you think it will slow down if we will continue doing so for long period of time?

Also, as I understand we keep history from the test run in nwaku, do we differentiate between tests run in js-waku or nwaku?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This steps runs only when the reusable test workflow ./.github/workflows/test-node.yml is called with allure_reports: true
And so far I only activated this for the main node job.
image
I think it will never take more than few seconds because I've setup a retention period of 30 reports

@fbarbu15 fbarbu15 requested a review from weboko October 23, 2023 10:28
@fbarbu15 fbarbu15 merged commit 80a33b9 into master Oct 23, 2023
9 of 11 checks passed
@fbarbu15 fbarbu15 deleted the chore/test-reports branch October 23, 2023 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E:End-to-end testing See https://github.com/waku-org/pm/issues/34 for details
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants