-
Notifications
You must be signed in to change notification settings - Fork 78
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
Node crate to folder #1632
Node crate to folder #1632
Conversation
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.
Relevant points
[package.metadata.wasm-pack.profile.release] | ||
# `wasm-opt` has some problems on linux, see | ||
# https:/rustwasm/wasm-pack/issues/781 etc. | ||
wasm-opt = false |
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 anyone know what was exactly the issue to check if it now works removing this? From the linked issue, it seems fixed, but I am not sure how to check it or evaluate it
@@ -1,30 +0,0 @@ | |||
[package] |
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.
AFAIK, this module is deprecated and can be removed
@@ -66,6 +41,7 @@ members = [ | |||
"pallets/rewards", | |||
"runtime/altair", | |||
"runtime/centrifuge", | |||
"runtime/development", |
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 can not tell why, but you can compile development even if it is not on the list. Anyways, adding it here for correctness
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.
Overall LGTM but I think the root Cargo.toml was emptied too much 😅
#!/usr/bin/env bash | ||
|
||
# Usage | ||
# ./scripts/tests.sh check|test "-F=feature1,feature2,..." <--no-run> | ||
|
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.
The comment is off, should refer to cargo_split.sh
instead of tests.sh
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 was named previously so, but now you can execute any cargo <command>
. That's why I changed the name to another more generic.
Thinking now that maybe even already exists such cargo tool 🤔
Seems the docker build command is failing. Could it be related to the last addition of #1646 ? Tested and "it works on my machine" |
8f7837a
to
2bfc5a4
Compare
As a test, I've reverted the already merged #1646, and now it works again. I'm quite lost, any suggestion @gpmayorga @wischli The CI job error is: https:/centrifuge/centrifuge-chain/actions/runs/7188961287/job/19579621674 |
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.
There are a few outdated code paths which want to pull chain specs from the root /res
not the moved /node/res
:
./docker/docker-compose-local-chain.yml
./docker/docker-compose-local-relay.yml
./scripts/run_collator.sh
@@ -20,8 +20,7 @@ FROM --platform=linux/amd64 docker.io/paritytech/ci-linux:production as builder | |||
WORKDIR /centrifuge-chain | |||
ARG FEATURES="" | |||
RUN FEATURES=$(echo ${FEATURES} | tr -d '"') \ | |||
cargo build --locked --release --features=${FEATURES} | |||
|
|||
cargo build -p centrifuge-chain --locked --release --features=${FEATURES} |
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.
@lemunozm Can you try reverting the revert and removing the -p centrifuge-chain
here? I have no clue how the pipeline change affects this PR, so this attempt is out of desperation.
cargo build -p centrifuge-chain --locked --release --features=${FEATURES} | |
cargo build --locked --release --features=${FEATURES} |
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'll try!
BTW, Thanks for notifying the above files 🙌🏻
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.
Just playing around with the above command, I'll try a cargo update
. Maybe the --locked
param is what is hitting us 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.
I tested everything and everything failed 🥲. Suuuper weird
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.
Tested locally and also fails.
This seems to be the issue: https://stackoverflow.com/questions/74643818/docker-buildx-gives-exit-code-137-with-cargo
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.
Tested locally and also fails.
This seems to be the issue: https://stackoverflow.com/questions/74643818/docker-buildx-gives-exit-code-137-with-cargo
IMO, the CI issue and Apple M1 docker build failures are unrelated. AFAIK, we cannot build our docker image locally on M1.
@lemunozm I deleted all cache related to this PR and re-ran the docker build manually in the actions and it succeeded 🎉 https:/centrifuge/centrifuge-chain/actions/runs/7206286656 Now re-scheduling the failed CI jobs here and hoping for deterministic behavior.
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.
Uooo! Cool!
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.
Then, I'm going to revert the cargo update
done and adding again -p centrifuge-chain
01425e7
to
f421f1d
Compare
852089a
to
3735e5d
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.
Super happy CI is finally bending the knee. Let's get this merged ASAP!
Thanks so much for all your help on this last issue @wischli 🙏🏻 |
@mustermeiszer @NunoAlexandre I think we need an approval from any of you 🙏🏻 |
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 disagree with moving the specs into the node folder. But no blocker.
Why not? Do they not belong to the node? Actually, those files are only referenced from the node crate. |
The spec is general for our chain. It should be usable by any node in theory or by any project without forcing them to depend in the node itself. |
Ok, that makes sense! |
I was thinking about this as well. I know at least two projects, which also moved the specs into the node directory and didn't raise this concern for that reason. But I definitely agree with out point that specs and the client are independent. |
Thanks for sharing the research! |
Maybe for now, we can keep it until we find the need to move this out (?) |
Description
Move the node and its dependencies to a
node
folderFixes #1278
Changes and Descriptions
res
src
build.rs
tonode
foldercargo build -p centrifuge-chain
scripts/tests.sh
intoscripts/cargo_split.sh
to filter by feature and reuse compilation artifacts, improving the speed. It takes around 20 min to compile all crates for one feature in my M1.subalfred
target toci/run-check.sh
for a feature CI job checking thisCurrent issue (when moving the node) SOLVED
When you compile the workspace, the same crate dependency built is used for different crates of the workspace. If different crates use the same dependency with different features, the first version in the compiling process is used for both. This leads to feature problems, such as the compiler complaining about missing features when the feature is actually correctly set in the crate.
When compiling the node along the workspace crate, all crates use dependencies that at least contain the features they need (probably because its dependencies are compiled first). Nevertheless, when moving the node out, the compiling order changes and causes some crates to use some dependencies with some features missing.
A simple
cargo check -F runtime-benchmarks
fails because some crate uses a previous artifact that was built withoutruntime-benchmarks
even when in itsCargo.toml
, the feature is correctly set.