Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Add tests & Service's Configuration has optional fields that shouldn't be optional #4842

Merged
merged 91 commits into from
Feb 21, 2020

Conversation

cecton
Copy link
Contributor

@cecton cecton commented Feb 6, 2020

Related to #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. 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.

@parity-cla-bot
Copy link

It looks like @cecton signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

@cecton cecton changed the title Fixing: Service's Configuration has optional fields that shouldn't be optional WIP: Fixing: Service's Configuration has optional fields that shouldn't be optional Feb 6, 2020
Forked at: 099cd0f
Parent branch: origin/master
@cecton cecton force-pushed the cecton-cli-service-configurations branch from 5ab624e to d0fc553 Compare February 6, 2020 14:53
…/master'

Commit: 4c34b64
Parent branch: origin/master
Forked at: 099cd0f
…/master'

Commit: 09abd3b
Parent branch: origin/master
Forked at: 099cd0f
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
…/master'

Commit: 19b67cd
Parent branch: origin/master
Forked at: 099cd0f
…/master'

Commit: 8b6b093
Parent branch: origin/master
Forked at: 099cd0f
…/master'

Commit: 26a4b73
Parent branch: origin/master
Forked at: 099cd0f
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Forked at: 099cd0f
Parent branch: origin/master
Copy link
Contributor

@gnunicorn gnunicorn left a 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!

bin/node/cli/tests/build_spec_works.rs Outdated Show resolved Hide resolved
client/cli/src/arg_enums.rs Show resolved Hide resolved
client/cli/src/commands/runcmd.rs Outdated Show resolved Hide resolved
cecton and others added 2 commits February 21, 2020 11:33
utils/frame/benchmarking-cli/src/lib.rs Outdated Show resolved Hide resolved
utils/frame/benchmarking-cli/src/lib.rs Outdated Show resolved Hide resolved
client/service/src/config.rs Outdated Show resolved Hide resolved
client/service/src/config.rs Outdated Show resolved Hide resolved
@@ -0,0 +1,69 @@
#![cfg(feature = "rocksdb")]
Copy link
Member

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

client/cli/src/params/transaction_pool_params.rs Outdated Show resolved Hide resolved
client/cli/src/params/mod.rs Outdated Show resolved Hide resolved
client/cli/src/params/mod.rs Outdated Show resolved Hide resolved
client/cli/src/node_key.rs Show resolved Hide resolved
Copy link
Member

@bkchr bkchr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See others.

@cecton
Copy link
Contributor Author

cecton commented Feb 21, 2020

Assuming the params and commands didn't change other than being split up, because I only gave them a rough glance ...

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.

Thanks for all the tests!

You're welcome! 🤗 I have hope to improve a lot sc_cli to a point where it would be very stable and intuitive.

&version,
)
Some(subcommand) => {
subcommand.init(&version)?;
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Member

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

bin/node/cli/src/command.rs Outdated Show resolved Hide resolved
bin/node/cli/tests/build_spec_works.rs Outdated Show resolved Hide resolved
bin/node/cli/tests/common.rs Show resolved Hide resolved
&version,
)
Some(subcommand) => {
subcommand.init(&version)?;
Copy link
Member

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)?;
Copy link
Member

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)]
Copy link
Member

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

Copy link
Contributor Author

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...

Copy link
Contributor Author

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

@cecton cecton merged commit 97ad802 into master Feb 21, 2020
@cecton cecton deleted the cecton-cli-service-configurations branch February 21, 2020 12:53
General-Beck pushed a commit to General-Beck/substrate that referenced this pull request Mar 4, 2020
…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.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants