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

Nim ping test #70

Merged
merged 11 commits into from
Dec 6, 2022
Merged

Nim ping test #70

merged 11 commits into from
Dec 6, 2022

Conversation

Menduist
Copy link
Contributor

@Menduist Menduist commented Nov 2, 2022

Should work fine now! No metrics though

Old message:


Works fine against itself, could use a hand to setup the interop tests themselves

I'm also not sure what format the pubsub payload should have, because it's being escaped
If I send {"publish": {"topic": "whatev", "payload": {"test": "whatev"}}
I receive something like "{"test": "whatev"}"

So I sent it as a string, which may fail with other implementations of the SDK

Also missing metrics since I don't support them in the SDK (yet)

@Menduist Menduist marked this pull request as draft November 3, 2022 12:38
@laurentsenta
Copy link
Collaborator

Awesome, thanks for sharing,

If you want to give this a shot:
you could create a all-interop-latest.toml, copy the content of https://github.com/libp2p/test-plans/blob/master/ping/_compositions/go-rust-interop-latest.toml and add a [groups] section with the nim builder. The section should look something like:

[[groups]]
id = "go-latest-{{ .Id }}"
instances = { count = 1 }
builder = "docker:go"
[groups.build]
selectors = ['{{ .Selector }}']
[groups.build_config]
path = "./go/"
build_base_image = 'golang:{{ .GoVersion }}-buster'
modfile = "{{ .Modfile }}"
(ignore templating for now).

On the payload:
that's how the sync service works at the moment (on my todo is to describe the current, implicit, spec).
You get the JSON back, encoded as a string.

Example in rust:
https://github.com/testground/sdk-rust/blob/2b85e4c9578037bd8704de40b7f179bf7fcc8649/src/responses.rs#L110

@Menduist
Copy link
Contributor Author

Menduist commented Nov 7, 2022

It works!

Had to fix a few things (the string thing, and the nim SDK doesn't signal initialized_global which is apparently required for the other SDKs, so I did it manually here), but seems to work fine now :)

Will have to find how to handle nim-libp2p versions properly, only need to specify a tag or a specific commit in the docker file here:

RUN nimble install -y "https://github.com/status-im/testground-nim-sdk@#c282ff68c08ef85a7ca011e077e3e69eb1a6edec"
RUN nimble install -y "libp2p"

This is how it's used in the testground nim sdk CI:
https://github.com/status-im/testground-nim-sdk/blob/c282ff68c08ef85a7ca011e077e3e69eb1a6edec/examples/simple_tcp_ping/Dockerfile#L6

But not sure how it integrates into all the templating stuff

@Menduist Menduist mentioned this pull request Nov 7, 2022
21 tasks
@laurentsenta
Copy link
Collaborator

Nice!

If all you need is a git commit, recommendation:
create a nim.toml which specifies multiple groups with an Id and a GitRef value.

Check the rust part, I guess it would look something like:

{{ with (load_resource "./nim.toml") }}
  {{ with (index .groups 0) }} // get the latest
    [[groups]]
    id = "nim-latest-{{ .Id }}"
    instances = { count = 1 }
    builder = "docker:generic"

    [groups.build_config]
      path = "./rust/"

    [groups.build_config.build_args]
      GIT_REF = '{{ .GitRef }}'
  {{ end }}
{{ end }}

@Menduist
Copy link
Contributor Author

Menduist commented Nov 8, 2022

Done, + an attempt at adding to CI

@Menduist
Copy link
Contributor Author

Menduist commented Nov 9, 2022

Workflow ran successfully on the fork: https://github.com/status-im/libp2p-test-plans/actions/runs/3427378367
So I would say this is ready for review

@Menduist Menduist marked this pull request as ready for review November 9, 2022 10:47
Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

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

🚀 happy to see this happening.

@@ -0,0 +1,45 @@
on:
Copy link
Member

Choose a reason for hiding this comment

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

Instead of introducing a new workflow file, how about including nim in ping-interop.yml. I don't see a reason why we should treat Go or Rust special.

Maybe @MarcoPolo has opinions here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ping-interop.yml will call the go-rust-interop.toml composition
So it could just call the all-interop.toml instead, but then the go-rust-interop.toml will never be called, and maybe it should be removed?
We would just have:

  • [language].toml: list of versions of that implem
  • [language]-cross-versions.toml: test every version of that implem
  • all-interop-latest.toml: test last version of every implem
  • all-interop.toml: test every version of every implem

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Did this in my latest commit, we can revert if not happy

Copy link
Member

Choose a reason for hiding this comment

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

We would just have:

* `[language].toml`: list of versions of that implem

* `[language]-cross-versions.toml`: test every version of that implem

* `all-interop-latest.toml`: test last version of every implem

* `all-interop.toml`: test every version of every implem

On a high level I am in favor of this. I will take a detailed look now.

@MarcoPolo MarcoPolo self-requested a review November 23, 2022 14:09
Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

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

Very excited for us to have interoperability tests beyond Go, JS and Rust.

The proposed changes here look good to me.

I suggest waiting for another review from @MarcoPolo (as self-requested).

In addition, I wonder how we should coordinate this with #53, i.e. how we should prioritize this and the refactoring of our test matrix generation. As far as I can tell, it would be fine to proceed here before #53. What do you think @jxs and @MarcoPolo?

.github/workflows/ping-interop-latest.yml Outdated Show resolved Hide resolved
Co-authored-by: Max Inden <mail@max-inden.de>
@Menduist
Copy link
Contributor Author

Soo the CI started to fail because of disk space usage:
https://github.com/status-im/libp2p-test-plans/actions/runs/3535301751
AFAICT, the Nim images are less than 1gb, and runners should have at least 14gb of disk available: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources
So I'm just unlucky enough to be the guy to reach this :D There are apparently some tricks to have more space in the runner, but using 14gb to build the images seems a lot to me, are the other implementation caching their dependencies properly to be reused by multiple images?

@mxinden
Copy link
Member

mxinden commented Nov 30, 2022

are the other implementation caching their dependencies properly to be reused by multiple images?

Would you mind merging master here @Menduist? #78 might resolve the issues you are seeing.

@mxinden
Copy link
Member

mxinden commented Nov 30, 2022

I suggest waiting for another review from @MarcoPolo (as self-requested).

Friendly ping @MarcoPolo. Any objections moving forward here?

@mxinden
Copy link
Member

mxinden commented Nov 30, 2022

Triggered the tests. All green @Menduist 🎉

@MarcoPolo
Copy link
Contributor

Looks great! @Menduist I'll ping you for some help in getting the multidimensional testing in the near future. Maybe we can pair on it? Might be fun to pair on some Nim 👑 👑 👑

@MarcoPolo MarcoPolo merged commit 003eb91 into libp2p:master Dec 6, 2022
@Menduist
Copy link
Contributor Author

Menduist commented Dec 6, 2022

Sure! Thanks for the merge 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants