Tests/relay publish

[fbarbu15]

First iteration of framework for interop/e2e tests:

• start/stop waku docker nodes and connect them in a network (2 for now but can be easily extended in future iterations)
• send and validate RPC or REST API calls
• begin a structure for scalable test (tests <- steps <- fixtures <- libs/helpers/data)
• ci runs via github actions
• allure reports via github pages that contain test and docker log attachments for failing tests
• automated linters and code formatting using pre-commit

Added only 2 basic tests for now but will extend after the initial set of reviews

[fryorcraken]

LGTM.

Really exciting.

[fryorcraken]

I would not spend too much time on JSON RPC because we want to deprecate it in favour of REST API.

[fbarbu15]

I've left it for comparison purposes. This way we can check that the REST API works the same as the old RPC protocol.

[fryorcraken]

It's ok to have some test for default pubsub topic but by default, you should now use shards.

[fbarbu15]

Makes sense, thanks

[jm-clius]

Great to see this progress!

[fryorcraken]

Do we intend to use @AlbertoSoutullo's new tool?

[AlbertoSoutullo]

Do we intend to use @AlbertoSoutullo's new tool?

We just had a meeting today about this topic. We both agreed to have two separated tools.

We will keep working on this repo for "small" tests. The main reason is to speed up the testing process as well as to be able to run these tests in a fast manner. One downside of Kubernetes is the time it takes to set up, run, and clean the runs. A test that can maybe run in 20 seconds can be a 3 o 4 minutes waiting scenario in Kubernetes.

I don't know if @fbarbu15 wants to add something but I think this pretty much summarizes what we talked in our call :)

[fbarbu15]

Do we intend to use @AlbertoSoutullo's new tool?

We just had a meeting today about this topic. We both agreed to have two separated tools.

We will keep working on this repo for "small" tests. The main reason is to speed up the testing process as well as to be able to run these tests in a fast manner. One downside of Kubernetes is the time it takes to set up, run, and clean the runs. A test that can maybe run in 20 seconds can be a 3 o 4 minutes waiting scenario in Kubernetes.

I don't know if @fbarbu15 wants to add something but I think this pretty much summarizes what we talked in our call :)

Thanks. In addition to enhanced speed, opting for this method over Kubernetes provides us with greater control and predictability regarding the messages sent and the assertions we must perform. Moreover, should an issue arise, it simplifies the process of identifying the problem and reproducing it for further investigation.
However, as Alberto and I discussed, once we've addressed the simpler scenarios and begin to tackle more complex ones, Kubernetes tool will come in handy.