-
Notifications
You must be signed in to change notification settings - Fork 379
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: add genesis command suite #1252
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1252 +/- ##
==========================================
+ Coverage 47.81% 47.91% +0.10%
==========================================
Files 369 372 +3
Lines 62742 63019 +277
==========================================
+ Hits 29997 30195 +198
- Misses 30293 30366 +73
- Partials 2452 2458 +6
☔ View full report in Codecov by Sentry. |
## Description This PR adds the `genesis verify` subcommand. Closes #1229 <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
## Description This PR adds support for the `genesis validator` sub-commands, as outlined in #1228. Closes #1228 Example `genesis validator add` command you can use to test out the functionality: ```bash genesis validator add --name milos -pub-key gpub1pgfj7ard9eg82cjtv4u4xetrwqer2dntxyfzxz3pqvknvnspy43c9zp0ts7wgvupldfzkws8kmvvz2eelfmzzupfymwpwzhh9m3 -address g1wpewvuxtyvqqwysndt4f8425tpdg3lf0mhu6fm ``` <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
## Description This PR introduces the `genesis balances` subcommand, as outlined in #1230. Closes #1230 <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests - [x] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
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 👍
Just a few points, but they're not mandatory for me.
Generally speaking, I prefer having mandatory flags as direct arguments when there aren't too many. It feel more natural to me
## Description This PR introduces the genesis.json command suite, as outlined in gnolang#1203. Closes gnolang#1203 and gnolang#1189 <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
## Description This PR introduces the genesis.json command suite, as outlined in gnolang#1203. Closes gnolang#1203 and gnolang#1189 <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
## Description Based on discussions in #1593, this PR introduces the CLI suite for manipulating the `config.toml`. Using this suite, we can build better workflows for power users. This PR is a series of lego blocks that are required for us to get a normal user chain connection going: - #1252 - solved `genesis.json` management and manipulation - #1593 - solved node secrets management and manipulation - this PR - solves `config.toml` management and manipulation All of these PRs get us to a point where the user can run: - `gnoland init` - `gnoland start` to get up and running with any Gno network. The added middle step is fine-tuning the configuration and genesis, but it's worth noting this step is optional. New commands: ```shell gnoland config --help USAGE config <subcommand> [flags] Gno config manipulation suite, for editing base and module configurations SUBCOMMANDS init Initializes the Gno node configuration set Edits the Gno node configuration get Shows the Gno node configuration ``` In short, the `gnoland config init` command initializes a default `config.toml`, while other subcommands allow editing viewing any field in the specific configuration. <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
## Description Based on discussions in gnolang#1593, this PR introduces the CLI suite for manipulating the `config.toml`. Using this suite, we can build better workflows for power users. This PR is a series of lego blocks that are required for us to get a normal user chain connection going: - gnolang#1252 - solved `genesis.json` management and manipulation - gnolang#1593 - solved node secrets management and manipulation - this PR - solves `config.toml` management and manipulation All of these PRs get us to a point where the user can run: - `gnoland init` - `gnoland start` to get up and running with any Gno network. The added middle step is fine-tuning the configuration and genesis, but it's worth noting this step is optional. New commands: ```shell gnoland config --help USAGE config <subcommand> [flags] Gno config manipulation suite, for editing base and module configurations SUBCOMMANDS init Initializes the Gno node configuration set Edits the Gno node configuration get Shows the Gno node configuration ``` In short, the `gnoland config init` command initializes a default `config.toml`, while other subcommands allow editing viewing any field in the specific configuration. <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details>
Description
This PR introduces the genesis.json command suite, as outlined in #1203.
Closes #1203 and #1189
Contributors' checklist...
BREAKING CHANGE: xxx
message was included in the description