-
Notifications
You must be signed in to change notification settings - Fork 84
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
Feat: LP integration tests #1720
Conversation
82aaa1a
to
0e3bb0a
Compare
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.
Really cool testing feature and added very clean! 🚀
Left some minor questions, suggestions and NITs. But everything is minor. Good job!
runtime/integration-tests/build.rs
Outdated
/* | ||
match Command::new("git") | ||
.args(&["fetch", "--all", "--recurse-submodules=yes"]) | ||
.output() | ||
{ | ||
Ok(o) if o.status.success() => {} | ||
Ok(o) => { | ||
println!( | ||
"cargo:warning=Git fetch failed with: \n - status: {}\n -stderr: {}", | ||
o.status, | ||
String::from_utf8(o.stderr).expect("stderr is utf-8 encoded. qed.") | ||
); | ||
} | ||
Err(err) => { | ||
println!("cargo:warning=Failed to execute git command: {}", err); | ||
} | ||
} | ||
*/ |
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.
Q: Should this always be done, or is it expected the developer does this manually before running these tests?
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.
+1. AFAICT, we should solve this via CI which regularly pulls the latest contracts
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 should solve this via CI which regularly pulls the latest contracts
One concern regarding this is that an update in liquidity-pools
can break our CI. I suppose it is centrifuge-chain
who should choose the commit used from liquidity-pools
. When liquidity-pools
is updated, then we should create a commit in centrifuge-chain
just updating the dependency.
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.
I am not 100% sure on the process here, tbh. @hieronx wdyt?
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.
When liquidity-pools is updated, then we should create a commit in centrifuge-chain just updating the dependency.
I think this makes sense. Also because we probably want to be able to run the main tests against the release commit from liquidity pools (what is live now), but also want to be able to run the tests in a branch against a more recent development commit. Having the commit be chosen manually would make this possible.
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.
IMO, the Liquidity Pools repo should include a CI which runs LP integration tests from Centrifuge Chain and notify Protocol / Centrifuge Chain repo when it is failing such that we know a breaking change has been introduced on the EVM side.
runtime/integration-tests/src/generic/cases/lp/pool_management.rs
Outdated
Show resolved
Hide resolved
.gitmodules
Outdated
[submodule "runtime/integration-tests/submodules/liquidity-pools"] | ||
path = runtime/integration-tests/submodules/liquidity-pools | ||
url = [email protected]:centrifuge/liquidity-pools.git | ||
branch = feat/local-router |
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.
Eventually, we want to use the main
branch here right?
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.
Good point! Curious too about this
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.
Feature branch for the local router we need for routing to local evm. Will be master once this is merged
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.
Main branch can be used now. cc @wischli
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.
Update: Main branch cannot be used as the LocalRouter
feat is required. We have been using the centrifuge-chain/release-v1.0
branch: centrifuge/liquidity-pools#260
Looks awesome so far @mustermeiszer! Thanks for taking care! |
runtime/integration-tests/src/generic/cases/liquidity_pools_transfers.rs
Outdated
Show resolved
Hide resolved
runtime/integration-tests/src/generic/cases/liquidity_pools_transfers.rs
Outdated
Show resolved
Hide resolved
.to_str() | ||
.expect("OsStr is utf-8. qed"); | ||
|
||
match Command::new("forge") |
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.
Should we add a small script for downloading a specific version of this or at least mention the version that is known to work. I guess we want to avoid having failures here by using a version that might behave differently.
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.
IMO, there definitely needs to be some improvement to this. Maybe it is sufficient to add forge
install to our init.sh
script for local development. For CI, forge is already installed manually. Eventually, there should be one codepath setting up requirements both for local development. as well as CI.
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.
I am unsure how to proceed here. I think for now, erroring out if forge
is not installed is fine, or should we install it during the build script - i mean locally in the build directory?
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.
or should we install it during the build script - i mean locally in the build directory?
I think this is the best option. The script should fetch locally everything it needs to work properly.
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.
Although compiling this implies compiling 900 crates 😅
runtime/integration-tests/build.rs
Outdated
let source = match parent { | ||
"liquidity-pools" => { | ||
println!( | ||
"cargo:info=Build liquidity-pools Solidity contracts. Stored at {} ", |
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.
cargo:info
doesn't seem to be supported.
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.
using warning now. Maybe confusing, but I think helpful to know where they are stored, wdyt?
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.
Yea, let's keep the warning for now, I wanna re-run everything on this branch later on and I think I'll need these ^^
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.
Maybe executing echo
and printing the info message can work to avoid the warning?
|
||
/* | ||
match Command::new("git") | ||
.args(&["pull", "--all", "--recurse-submodules=yes"]) |
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.
Note - Locally, I had to run a git submodule update --init --recursive
first.
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.
Do we want that in or should everybody pull the deps themselves?
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.
Hmm, probably not. But I think we should adapt some of the comments/error messages to in this part.
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.
Agree with @cdamian that we should modify the message.
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.
First review pass. Looks pretty clean despite the amount of code in the PR 💯
Just some Nits and question. Nothing important. In my second round I wanted to review the cases. Hopefully today or tomorrow
runtime/integration-tests/src/generic/cases/ethereum_transaction.rs
Outdated
Show resolved
Hide resolved
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.
LGTM! Let's merge this beast!
@cdamian I think we need your approval to get this in 💪🏻 |
Description
Currently, we can only test EVM <> Substrate interactions in the UI/testnetworks. This is cumbersome and not reliable for testing changes both on the Substrate as also on the EVM side.
This PR enables to write real e2e tests for both codebases.
Changes and Descriptions
*.json
files for creating contractstrait EvmEnv
that provides interaction with EVM in the test codebaseHow to test
If you encounter an error with an unset
LP_SOL_SOURCES
env var, the script did not build the solidity contracts intarget/debug/build/runtime-integration-tests-*/out/liquidity-pools
properly. Try removing allruntime-integration-tests
directories intarget/debug/build/
andruntime_integration_tests
ones intarget/debug/debs/
. If that doesn't help, clear the entiretarget
directory.Checklist: