Docs fixes (backport #368) (#373)

* Docs fixes (#368) * fixing broken link quick-start (#319) * fix link to point to relative page (#319) * fix link to point to rpc page (#319) * fix link that works for rpc (#319) * adding front matter to trigger hooks (#319) * add frontmatter to adr page (#319) * make link to configuration page relative (#319) * remove irrelevant text (#319) * updating relative link and removing irrelevant text (#319) * remove front matter from ADR (#319) * fixing broken links unders docs/tools (#319) * fixing broken links under spec/core (#319) * fixing broken links in spec/abci home (#319) * fix uparrows rendering and broken links (#319) * fixing links, comments on abci methods (#319) * fixing links in tutorials (#319) * adding a landing page for Apps (#319) * renaming qa v0.34 page to show in navigation (#319) * rename title of page for navigation (#319) * fixing links on abci client server (#319) * changes to allow RPC top level navigation on docs site (#319) * fixing some more broken references (#319) * reverting link change as per review (#319) * reverting link change as per review (#319) * reverting link in app-dev as per review (#319) (cherry picked from commit 28baba3) # Conflicts: # docs/core/rpc.md # docs/tools/debugging.md # docs/tutorials/go-built-in.md # docs/tutorials/go.md # spec/abci/README.md # spec/abci/abci++_basic_concepts.md # spec/abci/abci++_client_server.md # spec/abci/abci++_methods.md * fix conflicts * fixing rpc content (#373) * Update docs/core/rpc.md Co-authored-by: Daniel <[email protected]> * remove the inspect cmd info (#373) * remove RPC section tied to inspect cmd (#373) * fix rpc link (#373) --------- Co-authored-by: Andy Nogueira <[email protected]> Co-authored-by: Adi Seredinschi <[email protected]> Co-authored-by: Daniel <[email protected]>
celestiaorg · Feb 23, 2023 · c9f6511 · c9f6511
1 parent ab529de
commit c9f6511
Show file tree

Hide file tree

Showing 21 changed files with 64 additions and 24 deletions.
diff --git a/docs/app-dev/README.md b/docs/app-dev/README.md
@@ -5,3 +5,8 @@ parent:
 ---
 
 # Apps
+
+- [Using ABCI-CLI](./abci-cli.md)
+- [Getting Started](./getting-started.md)
+- [Indexing transactions](./indexing-transactions.md)
+- [Application Architecture Guide](./app-architecture.md)
diff --git a/docs/core/rpc.md b/docs/core/rpc.md
@@ -6,6 +6,6 @@ order: 9
 
 The RPC documentation is hosted here:
 
-- <https://docs.cometbft.com/v0.34/rpc/>
+- [RPC Documentation](https://docs.cometbft.com/v0.34/rpc)
 
 To update the documentation, edit the relevant `godoc` comments in the [rpc/core directory](https://github.com/cometbft/cometbft/blob/v0.34.x/rpc/core).
diff --git a/docs/introduction/quick-start.md b/docs/introduction/quick-start.md
@@ -119,6 +119,6 @@ cometbft node --home ./mytestnet/node3 --proxy_app=kvstore --p2p.persistent_peer
 
 Note that after the third node is started, blocks will start to stream in
 because >2/3 of validators (defined in the `genesis.json`) have come online.
-Persistent peers can also be specified in the `config.toml`. See [here](../cometbft-core/configuration.md) for more information about configuration options.
+Persistent peers can also be specified in the `config.toml`. See [here](../core/configuration.md) for more information about configuration options.
 
 Transactions can then be sent as covered in the single, local node example above.
diff --git a/docs/qa/README.md b/docs/qa/README.md
@@ -20,5 +20,4 @@ The results obtained in each release are stored in their own directory.
 The following releases have undergone the Quality Assurance process, and the corresponding reports include detailed information on tests and comparison with the baseline.
 
 * [TM v0.34.x](./v034/TMCore.md) - Tested prior to releasing Tendermint Core v0.34.22.
-* [v0.34.x](./v034/CometBFT.md) - Tested prior to releasing v0.34.27, using TM v0.34.x results as baseline.
-
+* [v0.34.x](./v034/README.md) - Tested prior to releasing v0.34.27, using TM v0.34.x results as baseline.
diff --git a/docs/qa/v034/CometBFT.md → docs/qa/v034/README.md b/docs/qa/v034/CometBFT.md → docs/qa/v034/README.md
diff --git a/docs/qa/v034/TMCore.md b/docs/qa/v034/TMCore.md
@@ -1,7 +1,7 @@
 ---
 order: 1
 parent:
-  title: CometBFT Quality Assurance Results for v0.34.x
+  title: Tendermint Core Quality Assurance Results for v0.34.x
   description: This is a report on the results obtained when running v0.34.x on testnets
   order: 2
 ---
@@ -274,4 +274,4 @@ transactions, via RPC, from the load runner process.
 
 Date: 2022-10-10
 
-Version: a28c987f5a604ff66b515dd415270063e6fb069d
+Version: a28c987f5a604ff66b515dd415270063e6fb069d
diff --git a/docs/tools/README.md b/docs/tools/README.md
@@ -11,7 +11,6 @@ CometBFT has some tools that are associated with it for:
 
 - [Debugging](./debugging.md)
 - [Benchmarking](#benchmarking)
-- [Testnets](#testnets)
 
 ## Benchmarking
 

diff --git a/docs/tools/debugging.md b/docs/tools/debugging.md
@@ -1,3 +1,7 @@
+---
+order: 1
+---
+
 # Debugging
 
 ## CometBFT debug kill

diff --git a/docs/tutorials/README.md b/docs/tutorials/README.md
@@ -6,5 +6,5 @@ parent:
 
 # Guides
 
-- [Creating a built-in application in Go][./go-built-in.md]
-- [Creating an external application in Go][./go.md]
+- [Creating a built-in application in Go](./go-built-in.md)
+- [Creating an external application in Go](./go.md)
diff --git a/docs/tutorials/go-built-in.md b/docs/tutorials/go-built-in.md
@@ -18,7 +18,7 @@ process as the application.
 
 By following along this tutorial you will create a CometBFT application called kvstore,
 a (very) simple distributed BFT key-value store.
-The application will be written in Go and  
+The application will be written in Go and
 some understanding of the Go programming language is expected.
 If you have never written Go, you may want to go through [Learn X in Y minutes
 Where X=Go](https://learnxinyminutes.com/docs/go/) first, to familiarize
@@ -749,12 +749,11 @@ The response contains a `base64` encoded representation of the data we submitted
 To get the original value out of this data, we can use the `base64` command line utility:
 
 ```bash
-echo cm9ja3M=" | base64 -d
+echo "cm9ja3M=" | base64 -d
 ```
 
 ## Outro
 
 I hope everything went smoothly and your first, but hopefully not the last,
 CometBFT application is up and running. If not, please [open an issue on
-Github](https://github.com/cometbft/cometbft/issues/new/choose). To dig
-deeper, read [the docs](https://docs.cometbft.com/v0.34/).
+Github](https://github.com/cometbft/cometbft/issues/new/choose).
diff --git a/docs/tutorials/go.md b/docs/tutorials/go.md
@@ -18,7 +18,7 @@ process as the application.
 
 By following along this tutorial you will create a CometBFT application called kvstore,
 a (very) simple distributed BFT key-value store.
-The application will be written in Go and  
+The application will be written in Go and
 some understanding of the Go programming language is expected.
 If you have never written Go, you may want to go through [Learn X in Y minutes
 Where X=Go](https://learnxinyminutes.com/docs/go/) first, to familiarize
@@ -673,12 +673,11 @@ The response contains a `base64` encoded representation of the data we submitted
 To get the original value out of this data, we can use the `base64` command line utility:
 
 ```bash
-echo cm9ja3M=" | base64 -d
+echo "cm9ja3M=" | base64 -d
 ```
 
 ## Outro
 
 I hope everything went smoothly and your first, but hopefully not the last,
 CometBFT application is up and running. If not, please [open an issue on
-Github](https://github.com/cometbft/cometbft/issues/new/choose). To dig
-deeper, read [the docs](https://docs.cometbft.com/v0.34/).
+Github](https://github.com/cometbft/cometbft/issues/new/choose).
diff --git a/rpc/openapi/README.md b/rpc/openapi/README.md
@@ -0,0 +1,12 @@
+---
+order: 5
+parent:
+title: RPC
+order: 5
+---
+
+# RPC
+
+The RPC documentation is hosted here:
+
+- [RPC Documentation](https://docs.cometbft.com/v0.34/rpc)
diff --git a/rpc/openapi/index.html → rpc/openapi/rpc.html b/rpc/openapi/index.html → rpc/openapi/rpc.html
diff --git a/spec/abci/README.md b/spec/abci/README.md
@@ -10,11 +10,11 @@ parent:
 ABCI stands for "**A**pplication **B**lock**c**hain **I**nterface".
 ABCI is the interface between CometBFT (a state-machine replication engine)
 and your application (the actual state machine). It consists of a set of
-_methods_, each with a corresponding `Request` and `Response`message type. 
-To perform state-machine replication, CometBFT calls the ABCI methods on the 
+_methods_, each with a corresponding `Request` and `Response`message type.
+To perform state-machine replication, CometBFT calls the ABCI methods on the
 ABCI application by sending the `Request*` messages and receiving the `Response*` messages in return.
 
-All ABCI messages and methods are defined in [protocol buffers](https://github.com/cometbft/cometbft/blob/v0.34.x/proto/abci/types.proto). 
+All ABCI messages and methods are defined in [protocol buffers](https://github.com/cometbft/cometbft/blob/v0.34.x/proto/abci/types.proto).
 This allows CometBFT to run with applications written in many programming languages.
 
 This specification is split as follows:

diff --git a/spec/consensus/evidence.md b/spec/consensus/evidence.md
@@ -1,3 +1,6 @@
+---
+---
+
 # Evidence
 
 Evidence is an important component of CometBFT's security model. Whilst the core
@@ -188,8 +191,8 @@ type LightClientAttackEvidence struct {
 
   // abci specific information
   ByzantineValidators []*Validator
-  TotalVotingPower    int64       
-  Timestamp           time.Time 
+  TotalVotingPower    int64
+  Timestamp           time.Time
 }
 ```
 

diff --git a/spec/consensus/light-client/README.md b/spec/consensus/light-client/README.md
@@ -4,6 +4,7 @@ parent:
   title: Light Client
   order: false
 ---
+
 # Light Client Protocol
 
 Deprecated, please see [light-client](../../light-client/README.md).
diff --git a/spec/consensus/signing.md b/spec/consensus/signing.md
@@ -1,3 +1,6 @@
+---
+---
+
 # Validator Signing
 
 Here we specify the rules for validating a proposal and vote before signing.

diff --git a/spec/core/data_structures.md b/spec/core/data_structures.md
@@ -1,3 +1,7 @@
+---
+order: 1
+---
+
 # Data Structures
 
 Here we describe the data structures in the CometBFT blockchain and the rules for validating them.

diff --git a/spec/core/encoding.md b/spec/core/encoding.md
@@ -1,3 +1,7 @@
+---
+order: 2
+---
+
 # Encoding
 
 ## Protocol Buffers
@@ -281,7 +285,7 @@ We call this encoding the SignBytes. For instance, SignBytes for a vote is the p
 
 ```protobuf
 message CanonicalVote {
-  SignedMsgType             type      = 1;  
+  SignedMsgType             type      = 1;
   sfixed64                  height    = 2;  // canonicalization requires fixed size encoding here
   sfixed64                  round     = 3;  // canonicalization requires fixed size encoding here
   CanonicalBlockID          block_id  = 4;

diff --git a/spec/core/genesis.md b/spec/core/genesis.md
@@ -1,3 +1,7 @@
+---
+order: 3
+---
+
 # Genesis
 
 The genesis file is the starting point of a chain. An application will populate the `app_state` field in the genesis with their required fields. CometBFT is not able to validate this section because it is unaware what application state consists of.
@@ -28,7 +32,7 @@ The genesis file is the starting point of a chain. An application will populate
 
 - `validators`
     - This is an array of validators. This validator set is used as the starting validator set of the chain. This field can be empty, if the application sets the validator set in `InitChain`.
-  
+
 - `app_hash`: The applications state root hash. This field does not need to be populated at the start of the chain, the application may provide the needed information via `Initchain`.
 
 - `app_state`: This section is filled in by the application and is unknown to CometBFT.
diff --git a/spec/core/state.md b/spec/core/state.md
@@ -1,3 +1,7 @@
+---
+order: 4
+---
+
 # State
 
 The state contains information whose cryptographic digest is included in block headers, and thus is