-
Notifications
You must be signed in to change notification settings - Fork 627
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
refactor: centralize&improve infrastructure for building test contracts #4160
Conversation
Backstory here: I've noticed that our |
61400d1
to
584b594
Compare
One thing I am not sure here is whether our python tests are guaranteed to run only after |
584b594
to
d17ac80
Compare
pub fn default_code_hash() -> CryptoHash { | ||
let mut path = PathBuf::from(env!("CARGO_MANIFEST_DIR")); | ||
path.push("../../runtime/near-vm-runner/tests/res/test_contract_rs.wasm"); | ||
let genesis_wasm = fs::read(path).unwrap(); | ||
hash(&genesis_wasm) | ||
hash(&near_test_contracts::rs_contract()) | ||
} | ||
|
||
lazy_static::lazy_static! { | ||
static ref DEFAULT_TEST_CONTRACT_HASH: CryptoHash = hash(&DEFAULT_TEST_CONTRACT); | ||
} | ||
|
||
lazy_static_include::lazy_static_include_bytes! { | ||
DEFAULT_TEST_CONTRACT => "../../runtime/near-vm-runner/tests/res/test_contract_rs.wasm" | ||
static ref DEFAULT_TEST_CONTRACT_HASH: CryptoHash = hash(near_test_contracts::rs_contract()); | ||
} |
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.
This seems to be some pre-existing duplication: default_code_hash
and DEFAULT_TEST_CONTRACT
compute the same thing. Left as is, as out of scope for the PR.
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.
Seems like tests are failing, lets fix that first. 😄
4d414c0
to
023a71d
Compare
@@ -0,0 +1,10 @@ | |||
[package] | |||
name = "near-test-contracts" | |||
version = "0.0.0" |
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.
Does 0.0.0 make sense?
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.
It does -- we are not going to publish this crate, so it doesn't have a meaningful semver. So putting a default 0.1.0
would be (a minor and insignificant) lie. 0.0.0
and publish = false
explicitly say that we don't care about semver in this case.
fn test_contract() -> ContractCode { | ||
ContractCode::new(TEST_CONTRACT.to_vec(), None) | ||
let code = if cfg!(feature = "protocol_feature_alt_bn128") { |
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.
This seems off to me. It should be based on whether nightly_protocol
is enabled.
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.
Probably! I've tried to keep pre-existing semantics in this PR, I can change this and that in a follow up.
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.
Took a look here, I am not sure how to fix it. This crate doesn't have nightly_protocol
feature:
[features]
# all vms enabled for tests, but only one default vm, specified by runtime crate
default = ["wasmer0_vm", "wasmtime_vm", "wasmer1_vm"]
wasmer0_vm = [ "wasmer-runtime" ]
wasmtime_vm = [ "wasmtime", "anyhow"]
wasmer1_vm = [ "wasmer", "wasmer-types", "wasmer-compiler-singlepass", "wasmer-compiler-cranelift", "wasmer-engine-native", ]
lightbeam = ["wasmtime/lightbeam"]
no_cpu_compatibility_checks = []
protocol_feature_evm = ["near-primitives/protocol_feature_evm", "near-evm-runner/protocol_feature_evm"]
no_cache = []
protocol_feature_alt_bn128 = [
"near-vm-logic/protocol_feature_alt_bn128",
"near-primitives/protocol_feature_alt_bn128",
"near-vm-errors/protocol_feature_alt_bn128"
]
At this point, I don't know the purpose of nightly_protocol
and nightly_protocol_features
cargo features and why they are set up that way, so I can't immediately fix that. Learning more about our feature setup is on my todo list, so I might come back to this later.
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.
@matklad nightly_protocol is supposed to be a marker feature near/NEPs#126 (comment)
247b8a0
to
6420c4a
Compare
Got this past CI, including the "One thing I am not sure here is whether our python tests are guaranteed to run only after cargo build" bit. should be ready for review. |
* Move test contracts to the dedicated `runtime/near-test-contracts` folder * Do not commit `.wasm` files and instead re-build them on the fly when necessary * Use build.rs rather than build.sh for compilation * Replace lazy_static_include calls with centralized functions
6420c4a
to
08f7cb6
Compare
format!("./res/{}.wasm", output), | ||
)?; | ||
println!("cargo:rerun-if-changed=./{}/src/lib.rs", dir); | ||
println!("cargo:rerun-if-changed=./{}/Cargo.toml", dir); |
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.
What are these println?
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.
They tell cargo when it needs to rebuild the test contracts, These are documented in https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script
In theory, we maybe can just always run cargo build
here, as that should be a no-op, but it wasn't hard to save an extra process invocation here.
They were extracted out of near-vm-runner in near#4160 but I forgot to update codeowners.
* add myself as a codeowner * fixup #4160 to re-install codeowners for the new crate.
runtime/near-test-contracts
folder.wasm
files and instead re-build them on the flywhen necessary