-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Add tests & Service's Configuration has optional fields that shouldn't be optional #4842
Conversation
It looks like @cecton signed our Contributor License Agreement. 👍 Many thanks, Parity Technologies CLA Bot |
5ab624e
to
d0fc553
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.
Assuming the params and commands didn't change other than being split up, because I only gave them a rough glance ...
Thanks for all the tests!
(might not work)
Co-Authored-By: Benjamin Kampmann <[email protected]>
client/service/src/benchmark.rs
Outdated
@@ -0,0 +1,69 @@ | |||
#![cfg(feature = "rocksdb")] |
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 whole benchmark command was moved to its own crate utils/frame/benchmarking-cli
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.
See others.
Yes well it was complicated because a lot of changes have been pushed to master, especially yesterday. TL;DR: I'm very confident nothing has been lost. Long story: I'm experimenting a new workflow where I merge the most non-conflicting commits to my branch to update it and then I create a single merge commit with the conflicting commit where I solve the issue independently. Because of that, I look at the commit carefully and I replicate the changes in my files properly. It's a bit like what happen with rebase (resolving conflicts commit by commit) except that it's merging instead of rebasing.
You're welcome! 🤗 I have hope to improve a lot |
Co-Authored-By: Bastian Köcher <[email protected]>
Co-Authored-By: Bastian Köcher <[email protected]>
Co-Authored-By: Bastian Köcher <[email protected]>
Co-Authored-By: Bastian Köcher <[email protected]>
Co-Authored-By: Bastian Köcher <[email protected]>
Co-Authored-By: Bastian Köcher <[email protected]>
Co-Authored-By: Bastian Köcher <[email protected]>
Co-Authored-By: Bastian Köcher <[email protected]>
&version, | ||
) | ||
Some(subcommand) => { | ||
subcommand.init(&version)?; |
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.
Why aren't init
and update_config
not done inside of run()
? Someone could just call run()
without calling the other methods before and it would be incorrect.
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.
Because for cumulus we want to be able to modify the config before running the node.
We could have another "run" command that would do all 3 commands but we need to keep the existing 3.
Since a helper would simply call init & update_config & run, I thought it wouldn't be super helpful and I have not added it.
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 removed the run and run_subcommand helpers as they are not helping much anymore. Running a command is always a set of 3 commands: 1. init 2. update config 3. run. This still allow the user to change the config before arguments get parsed or right after.
😱 you didn't read the PR description
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.
Code is law :P
Yeah it is okay for now. However it could happen that the user just calls run()
(because nothing prevents them) and it will break.
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.
And this "pattern" is a let's repeat some code "pattern" :D
Co-Authored-By: Bastian Köcher <[email protected]>
Co-Authored-By: Bastian Köcher <[email protected]>
&version, | ||
) | ||
Some(subcommand) => { | ||
subcommand.init(&version)?; |
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.
Code is law :P
Yeah it is okay for now. However it could happen that the user just calls run()
(because nothing prevents them) and it will break.
&version, | ||
) | ||
Some(subcommand) => { | ||
subcommand.init(&version)?; |
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.
And this "pattern" is a let's repeat some code "pattern" :D
@@ -14,7 +14,14 @@ | |||
// You should have received a copy of the GNU General Public License | |||
// along with Substrate. If not, see <http://www.gnu.org/licenses/>. | |||
|
|||
use std::{process::{Child, ExitStatus}, thread, time::Duration}; | |||
#![cfg(unix)] | |||
#![allow(dead_code)] |
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 is dead inside here? :P
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 don't know. I think common.rs is executed on its own...
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.
So everything looks like dead code when it's compiled
…t be optional (paritytech#4842) Related to paritytech#4776 Related to paritytech/polkadot#832 To summarize the changes: 1. I did not manage to validate with types the service's Configuration. But I did reduce the possibility of errors by moving all the "fill" functions to their respective structopts 2. I split params.rs to multiple modules: one module params for just CLI parameters and one module commands for CLI subcommands (and RunCmd). Every command and params are in their own file so things are grouped better together and easier to remove 3. I removed the run and run_subcommand helpers as they are not helping much anymore. Running a command is always a set of 3 commands: 1. init 2. update config 3. run. This still allow the user to change the config before arguments get parsed or right after. 4. I added tests for all subcommands. 5. [deleted] Overall the aim is to improve the situation with the Configuration and the optional parameters, add tests, make the API more consistent and simpler.
Related to #4776
Related to paritytech/polkadot#832
To summarize the changes:
I updated some feature flags with the new benchmark subcommands because client/cli couldn't build anymore. So I added a flag rocksdb[edit: it has been fixed in master and this is no longer necessary so I removed it]Overall the aim is to improve the situation with the Configuration and the optional parameters, add tests, make the API more consistent and simpler.