[ci] Add workflow

[alvicsam]

cc https://github.com/paritytech/ci_cd/issues/960

[dmitry-markin]

Thanks! Is it possible to make all 4 independent tests, so it's instantly visible what check is failing?

[alvicsam]

Sure, added. The jobs have the same CI image (image: "paritytech/ci-unified:bullseye-1.75.0-2024-01-22-v20240222") in order to not repeat it several times we can add it to repo environment variables (but I need permissions for that)

[dmitry-markin]

@alvicsam it seems a loopback interface is not enabled in the container. All the "real" networking tests fail with

called `Result::unwrap()` on an `Err` value: Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" }

Can you have a look, please?

[dmitry-markin]

The jobs have the same CI image (image: "paritytech/ci-unified:bullseye-1.75.0-2024-01-22-v20240222") in order to not repeat it several times we can add it to repo environment variables (but I need permissions for that)

That would be nice. What kind of permissions do you need? What would be the best way forward to keep the image in sync with polkadot-sdk repo tests (so that at least the rust toolchain is the same)?

[alvicsam]

Can you have a look, please?

Sure, I'll take a look

What would be the best way forward to keep the image in sync with polkadot-sdk repo tests (so that at least the rust toolchain is the same)?

This is a really good question. The problem is actually bigger because there will be more and more repos that will depend on the same CI image that is used in polkadot-sdk repo. I will create an issue in our tracker with thoughts how we can achieve that.

As for permissions I'll ask the security team to provide them.

[alvicsam]

@dmitry-markin it seems I need your help with the tests
Tests in container fail with the error you sent (even if the container runs in the privileged mode). Without container it hangs on test protocol::request_response::large_response_quic has been running for over 60 seconds

[dmitry-markin]

@dmitry-markin it seems I need your help with the tests Tests in container fail with the error you sent (even if the container runs in the privileged mode). Without container it hangs on test protocol::request_response::large_response_quic has been running for over 60 seconds

My guess is that the issue can be due to loopback inteface not being present / being down. What was the output of ip a in the commit ci image var, check lo? If the lo interface was down, it should be brought up with ip link set lo up (probably appropriate privileges are required), and if it's not — there is something severely off with the networking in the container.

If lo is present and is up, we'll need to investigate further.

[alvicsam]

I could run a simple http server on the lo interface so it's available.

[dmitry-markin]

I could run a simple http server on the lo interface so it's available.

Thanks, I'll think how to investigate the problem.

[dmitry-markin]

Not sure what kind of machines the CI uses but is it possible that the request timeouts when it's trying to create the 15MiB response? I remember generating large number of random bytes was somewhat CPU intensive when I ran some tests locally so if the test would instead generate 15MiB vector of zeros before sending the request (swapping the order of these lines), would that make it pass?

It worked, and I also removed golang conformance tests, so now we should have all tests passing.

[lexnv]

I'm happy to merge this whenever you think is ready! 🙏

[dmitry-markin]

I'm happy to merge this whenever you think is ready! 🙏

CC @alvicsam

[dmitry-markin]

@lexnv We should probably agree on the merge strategy for the repo. Personally I'm for squash & merge, we could also do a merge commit, and I don't think we should ever rebase & merge.