-
Notifications
You must be signed in to change notification settings - Fork 43
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
Nim ping test #70
Conversation
Awesome, thanks for sharing, If you want to give this a shot: test-plans/ping/_compositions/go-rust-interop-latest.toml Lines 18 to 29 in b97b36a
On the payload: Example in rust: |
It works! Had to fix a few things (the string thing, and the nim SDK doesn't signal 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: test-plans/ping/nim/Dockerfile Lines 3 to 4 in c8e4b32
This is how it's used in the testground nim sdk CI: But not sure how it integrates into all the templating stuff |
Nice! If all you need is a git commit, recommendation: Check the {{ 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 }} |
Done, + an attempt at adding to CI |
Workflow ran successfully on the fork: https://github.com/status-im/libp2p-test-plans/actions/runs/3427378367 |
There was a problem hiding this 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: |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 implemall-interop-latest.toml
: test last version of every implemall-interop.toml
: test every version of every implem
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this 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?
Co-authored-by: Max Inden <mail@max-inden.de>
Soo the CI started to fail because of disk space usage: |
Friendly ping @MarcoPolo. Any objections moving forward here? |
Triggered the tests. All green @Menduist 🎉 |
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 👑 👑 👑 |
Sure! Thanks for the merge 🎉 |
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)